In Praise of the Business Plan, Jerry Neumann, a venture investor and startup instructor warns that VCs who focus too much on the product demo, are doing entrepreneurs a disservice. He says they should ask founders to write a business plan that takes into account the customer, the market, and how their company will “solve pain and endlessly scale”. Jerry makes a good point that the VC is typically not the customer, so their feedback shouldn’t be that relevant. But I don’t think that’s a reason to entirely dismiss a VC’s feedback. VCs have learned how to ask the right questions about a product, whether they are the target end-user or not. Fred Wilson agreed with Jerry’s sentiment, but not with the substance of the post as it relates to dissing the product demo. Fred says in the comments, “I agree that you need more than a demo. You need a deck that explains why you built what you built and how you intend to make it into a business. But showing the product to a VC is not about addressing the technical risk. It is about showing that you have the ability to build a product that is useful, easy to use, and does in fact address the problem in a way that will be successful.” Fred’s statement is very relevant to planning, because you can’t answer these questions if you haven’t thought about them for a while.

The End of Requirements?

In The End of Requirements, Marty Cagan of the Silicon Valley Product Group advises product teams to not think of actual requirements, but rather to define products in terms of two key dimensions:
  • Unmet vs. Unrealized needs
  • Customer-inspired vs. Technology-inspired solutions
The premise is that unrealized needs are ones where customers aren’t even aware they have that need, “until after they see and experience the solution.” Customer-inspired is derived by observing the customer experiencing some pain, and technology-inspired is when an advancement in technology becomes a trigger to a better solution, e.g. a new algorithm, a new battery or a new cloud solution. Marty sees the trend tilting in favor of more technology-inspired solutions that meet unrealized needs. But in an email exchange I had with Tom Eisenmann of Harvard Business School, Tom told me: “If Marty is correct with his assertion that an increasing fraction of product teams are working on unrealized needs and tech-inspired solutions, then we really would need to think through product management processes, including requirements gathering, since unrealized needs pose distinctive market research challenges.” Tom’s question is a valid one, although I don’t see startup founders going to great length at collecting market requirements or conducting diligent market research. Rather, they start with a gut instinct when they see an unmet need, or are driven by a sense of mission when they suspect there is an unrealized need, then proceed to build a product to demonstrate how it can address those needs, or if it can create new ones. Think iPhone, and the proverbial Steve Jobs quote “People don’t know what they want, until you show it to them.” Tom has another great point in suggesting to me that “unrealized needs might be more aptly named ‘unrecognized’ needs since 1) consumers don’t recognize these needs exist, and 2) ‘unrealized’ implies unsatisfied, and that’s true for ‘unmet’ needs, too.” Tom’s perspective is well grounded, especially that he teaches Product Management 101, a learning-by-doing (as contrasted with the classic HBS case method approach) HBS MBA course he has developed. In this recent post titled Critique of PM101 Market Requirements Documents, Tom’s narrates a critique of that course, which is meant to highlight ways that new product managers and first-time founders might struggle when they assess customer demand. It is a great read, because the course’s assignment strikes a balance between agile development methods, and stricter waterfall techniques. It argues that students enhance their understanding of agile after they experience waterfall techniques first-hand. I really like the part that explained how surveys should, or should not be used for. Here’s a Google Docs link to a light-weight MRD (Market Requirements Document) version from Tom’s course, which could be a useful starting point for a new product manager. The learnings from that course are well documented by Tom in his post, and apply to any startup. A bit of theoretical grounding won’t hurt any startup that is typically on a fast and furious frenzied pace of product evolution.

Take aways

Product Pitch
  • Do your demo with the aim to show the usefulness of your product in solving a known problem
  • Explain why you built the product the way you did
  • Describe how you intend to turn the product into a business
Product Requirements
  • Think unmet vs. unrealized / unrecognized needs and keep a balance between technology-driven vs. customer-inspired solutions
Product Management Process
  • Stay agile, but don’t trample on some basics pertaining to useful research, customer interviews, focus groups or surveys approaches.
So, take a balanced approach. You need some planning, but not too much of it.
Use planning to answer questions, rather than to produce a document.
]]>