Recently I received a query via email that I thought would make a good blog post:
How do you conceptualize what software would be useful to an industry? More specifically, how did you determine that VMware storage automation applications would be useful in a large context to industry, and how did you design your method of accomplishing this task to be more efficient and desirable than the internal to VMware and your competitors?
You don’t have to answer in specifics of course, but I’m suffering from a classic “coders block” on applications that might be useful to a broad context and wondered if you had any advice on that topic.
I have brought seven products that I either invented or co-invented to market, and worked on about six other products in a major way.
The products that were successful came out of the following criteria:
- What am I uniquely able to bring to market? I.e., what are the capabilities of my own technical skills, knowledge, and other people that I know who I could convince to work for me? What scope of products can we create? What ideas, out of that entire range of possibilities, are unique and are based on insights or experiences that few others have?
- What’s missing from the market place? Of the things that I can uniquely do, what of those can be applied to things missing in the market?
Any market worth being in is busy. If no one is there trying to make money to solve the problem you’re solving, with some type of offering, it’s not worth being in that market. Some of the market scoping you can decide–and how you decide this will drive how you talk about your offering. If you scope too narrowly, no one will fit your target audience. Scope too broadly and no one will be able to find you. Sometimes it is tricky to know what market you’re in; you might think you’re selling software, but your customers buy your product as insurance. Or maybe you think you’re selling shirts but you’re actually selling a lifestyle.
My first serious business was a Mac software business, selling casual games that were targeted to smart women in their 40s who wanted a tough mental challenge. This was an underserved market at the time–few casual games existed beyond Tetris and few were sold with a concept of being “difficult”. Anyone can “match three” like Bejeweled, and lots of people like doing it, but can you solve this puzzle? With my first product for that business, I hadn’t quite identified what the target was–in fact, the first game was more of a concept test–could I finish a product, release it, get people to my web site, get them to give me their money, send them a license key, support the software, and so on? As it turned out the answer was yes. The second game I did was much more targeted to my audience defined above–and sold 100x more copies. While there was nothing specific in the game tailored to women, and I certainly had plenty of male customers too, I wrote advertising messages and picked placements that were targeted to women because I felt that my message was unique and unexpected vs other ads women might expect to see in those places.
The word “innovation” has gotten a lot of attention these days. I took a class at MIT’s Executive training program last year on managing innovation in large organizations. One of the key things one of the professors pointed out in the class was that innovation without solving a customer need is completely useless. This should be fairly obvious, but I’ve seen plenty of people lose sight of this fact.
So when you’re building a new product, you need to be solving a real customer need. That brings us back to the original question: What process enables you to figure out what would be useful?
At my last company, my partner and I spent hours just chatting about ideas–I would estimate over the course of four years, we spent over 800 hours brainstorming. What if there was a way to do X? What about Y? What if you did Y but with a hint of X? Would anyone care? We were developing products in an industry that we knew well–I had about 4 yrs of experience in that market and he had about 15. So we knew a lot of the attitudes of our customers, a lot of the concerns, some of the common problems that those customers face day in and day out. We were bringing our understanding of that market to a semi-new but semi-related space. We kept the brainstorming going from the very beginning when we first had the idea all the way through until when I left the company after we were acquired. We came up with several ideas for things we never shipped and a few key ideas that we did ship and did well.
Tied into our brainstorming, we did a lot of market research. Long before we had employees or venture capital, I was pounding the pavement, visiting customers, calling customers, searching Google for people posting in forums about the problems we wanted to solve, and posting on Twitter inviting people working with certain tools in Boston or San Francisco out for having a beer with me. We also did surveys with Constant Contact to help quantify what we were finding organically with people we could manually reach. The organic side helps find stories, and structured surveys with the right audience can help define priorities or narrow a focus once you’re able to describe better what you think is important.
If you want to build something big, you need to attach to a market trend that is real. Lots of people understand this, which is why you see so much “Mobile is the next big thing”, “Cloud is the next big thing”, and so on. But you still have to solve a real problem–in a market trend that is real–and not get creamed by the big players in that space. We felt the virtualization trend was real, so were comfortable attaching to that. Lots of companies saw this as well and tried building small, simple products, such as performance monitoring tools for VMware–but VMware is good at adding those features pioneered by third parties to their own management applications. At the end of the data, these companies were just publishing numbers exposed by VMware APIs into a UI or reporting system. The bar to duplicate that was very low. So you have to focus on problems that are hard to duplicate or spaces that are related but not in the big vendor’s core competencies.
There’s lots to be said about the process of inventing new products. Many people talk about Clayton Christensen’s book The Innovator’s Dilemma, but from a process perspective, some of the activities discussed in one of his other books, The Innovator’s DNA, is worth reading to see how folks approach solving these problems. I have had a copy of The Product Manager’s Desk Reference by Steven Haines in my bookcase for a while now, and while I haven’t read it cover-to-cover, it does cover a number of the research activities required to build a new product all the way through launch. And of course, there is the classic book Winning at New Products by Robert Cooper.
Elsewhere on this blog, I have previously written about some related issues with starting a new company. If you are starting a new company, be sure to check it out!
