I ‘ve spent a significant part of my career designing and building enterprise software products for both large and small companies across many industries. A few weeks ago I embarked on an exercise to find out what made some of them wildly successful while others floundered. Here is what I found separated the winners from the losers…
Align with your company’s mission
Products don’t live in a vacuum; they need the rest of your company to succeed. If your mission is to e.g., make sales professionals more productive, think hard before deciding to also target e.g., HR professionals because there are only ‘minor tweaks required for the product’. Even if they are (which they seldom are), what about your sales and marketing functions? Can they scale to now support the needs of a very different buyer? If you are in a large, established company you have the resources and time to buy yourself into new markets. This is very difficult, if not impossible, for young companies.
Find a real pain point your customers are willing to pay for
As product managers we often forget to ask if anyone really cares about a product or feature. Large companies have many resources, from the large analyst firms like Gartner, IDC, Forrester, etc., to the independent analysts and consultants that will craft together surveys and customer interviews. Small ones don’t. What they do have however is customers, or even friends in the target buyer roles for their product. Sketch your idea and ask them if it solves a real pain point. Go a step further and ask them how much they would be willing to pay if you were to actually make their pain point go away. You ‘d be surprised how many would actually tell you whether your great new idea is something they would pay for.
Manage the scope (a.k.a. don’t attempt to solve world hunger)
I am a big proponent of focus and experimentation. It ’s very easy to design something that will require 2 years before you can actually bring it to market, at which point the market may be at a different place. In many cases, your new product may be so revolutionary and involved that it may just require this much time; in my experience this is rarely the case. Even if it does however, you need to break it up in more manageable components. Challenge yourselves to see if you can deliver 80% of the value with only 20% of the resources. You ‘d be surprised to find out how much you can accomplish and how much you ‘ll learn by starting focused. My last company’s first product solved a ‘simple’ problem of helping companies measure the effectiveness of social media activities around their customers’ events and we did that very well. While not a huge market, it helped us learn the market and establish credibility with our customers that subsequently led to the addition of more use cases. I would argue that would have been impossible had the company started by attempting to build an end-to-end social marketing solution.
Focus on the user experience
I have been a proponent of user experience for quite some time. My friend and enterprise software guru Jon Reed wrote a great 2-part post on user experience a couple of weeks ago. While I fully agree with Jon that this is much over-hyped topic (and has been since Consumerization of IT first emerged as far back as 2001), user experience does matter. As the buying power has continued to shift away from IT into the lines of business and as these enterprise users get accustomed to [pick your favorite consumer product], they increasingly demand a similar user experience from the products they use at their professional lives.
Yes, I do realize that the process of designing and building enterprise software products is a lot more complicated and there are companies whose sole purpose is to help companies crack the art and science of product management. These simple principles however have served me well over the years whether I was adding a feature or building a full-fledged product. As matter of fact, I have used these principles when planning new releases for existing products and they have seldom failed me.
What do you think? What are the core principles you apply when building enterprise software products?