Product planning series: Planning a new web app

[tweetmeme source=”chenelaine” only_single=”false” service=””]
I’ve been working with students quite a bit at the MIT Entrepreneurship Center this semester. One class of questions that keeps coming up surrounds how you actually take an idea and make something out of it. In particular, lots of technical people know how to do the bleeding edge research and get something up and running for the first time, then they get stumped at the point where they have to take an idea (represented in, say, 3 powerpoint slides) and a proof-of-concept technology demo, and take it all the way to V1 release.

Before you start any development work, it is important to frame the program from a business case and financial merit standpoint. The first question to ask is, what is the objective of this whole thing? Whatever the product or service you are trying to develop, you need to have a clear idea of what you are doing and why, and for what set of customers. You also need to clearly understand what you and/or other stakeholders like investors, partners and customers can expect to get out of it. If you haven’t figured that out, you are developing a technology, much less a product or service and especially not a new business around your proposed offerings.

Let’s take a new web based business as an example. Suppose we hypothetically say that “this whole thing” is a novel B2C consumer SaaS play. Some questions to ask at this stage include:

  • What is the market segment you want to target and why? (This forms the basis of your total available market)
  • What are the market problems of this target segment that will drive them to adopt your new offering? What problems are they facing – where are the pain points?
  • What are the defining characteristics of this segment (e.g. demographics breakdown, typical education, household income, all that good stuff”
  • What is the size of this market segment (by headcount, company count or some such – not by dollar amount)?
  • What is the product concept to solve this problem at the 50,000 feet level?
  • What is the likely size of the subsegment that will be addressable by the way you propose to solve this problem? (This forms the basis of the addressable market. For instance, if your offering involves an iPhone app, then your addressable market becomes the part of the target segment who owns an iPhone. Your total addressable market becomes limited by the penetration of someone else’s product or service.)
  • How are you proposing to charge for your product or services?
  • Now put the market sizing information, the pricing structure and so forth in a spreadsheet, run it out for 5 years and do a quick model to see whether you think the economics make sense. Don’t spend more than 30 minutes doing this – the purpose is to use this framework to help you think through factors that matter in the business case. This spreadsheet is mostly worthless as a tool to predict how your business will work because you have insufficient data at this point.
  • Having done all of the above, are you still happy with your idea, who you are serving and what you and other stakeholders will get out of x months of hard work and $y of investor money?

Now we all know the term “MRD” (a.k.a. “Market Requirements Document”) is no longer in vogue. Everybody wants to be fast, agile and not be tied down with piles of documentation. MRD is associated with the waterfall process and that’s very much frowned upon in this day and age. However, in my opinion you just don’t go into any major new initiative without doing some of this due diligence. I am against writing a large 35 page word document, but I do very much support thinking through these key points, gathering any and all facts you can get your hands on, and putting it all together in a powerpoint presentation, and using that as a communication vehicle to achieve alignment at all top level. Without this alignment a development program is pretty much doomed from the get-go – the engineers in the trenches could be working on large sections of code that are based on false assumptions and it would result in nothing but aggravation and frustration in the end.

Only after you have answered the above questions should you proceed to the development stage (which includes product requirements gathering, specifications, design, wireframing, then finally, coding. Coding comes last.) If you go through this thought process and can’t come to terms with what you find out, you should revamp the assumptions that led you to this new offering and pivot or adjust.

Now it is perfectly acceptable to go through this exercise and say “but we don’t know” or “the financials really doesn’t matter because this offering is a hook to help acquire customers for another more lucrative business”. But there is every difference between rushing ahead to do something without thinking through the implications and going into something knowing all the assumptions and facts. I’m a big fan of the latter – it usually leads to better results.

There is a lot more to discuss on how to go about answering my bulleted questions and how to actually plan and execute the development portion of the program. I will be filling in those posts over the next few weeks.

List of posts in this series:


13 Responses to “Product planning series: Planning a new web app”

  1. 1 Scott Sehlhorst April 13, 2011 at 7:37 am

    Hey Elaine, great post, I’m excited to see how your series pans out, and hope you follow it up with some stories tracking the progress of your students! Will be interesting to see where they stumble, what they end up getting the most value from, etc.

    I really really like the last sentence of your next-to-last bullet: “mostly worthless as a tool to predict…”

    IMHO, you’re spot on.

    When I’m doing this exercise early on, I do this same step – but I don’t think of it as “the business case” – I think of it as “sizing the potential opportunity.”

    These rough estimates of _potential_ market size are exactly that – they identify how big the space is, how much head room you have, and essentially, if you create the perfect product – with the perfect launch plan – how big _might_ things get for you.

    This is a great way to eliminate _uninteresting_ problems before you invest in creating solutions.

    As you point out – MRD is not en vogue these days – and the reason is because the “35 pages” you create at this stage are of little value. However, once you finish the who/what/why/how at the next step, you can revisit this analysis and do what I think of as the business case – making a case for how much of this potential opportunity you think you can capture.

    Thanks again for the series!

  2. 2 Elaine Chen April 13, 2011 at 6:21 pm

    Hi Scott,

    I’m glad I’m not the only one who thinks an elaborate financials spreadsheet this early in the game is worthless 😀

    Seriously, I haven’t written a 35 page MRD in 10 years. What I do instead is a 10 page requirements powerpoint that puts stakes in the ground regarding market sizing and analysis (citing sources), clarifying target market segment, stating market problem and explaining why this represents unmet needs, sketching out a concept for the solution, clearly stating the UVP for each key constituent – you know, all that basic stuff that explains why this product deserves to exist.

    It is very much an iterative process with the who/what/why/how but all this wants to be hashed out and communicated before we start any development project – otherwise the project is doomed to fail due to lack of alignment.


  3. 3 Scott Sehlhorst April 14, 2011 at 8:06 am

    Really really great point about lack of alignment as a killer of projects! Way too easy to develop a myopic view of “technology purity” and get blindsided by lack of sponsorship.

    Especially important when working with students, who may have been otherwise inundated with theoretical perspectives.

    Looking forward to the next in the series!

  4. 4 Matt October 2, 2012 at 12:30 pm

    These are a fantastic set of posts—a pithy synthesis of the latest thinking in product management/development. We’ve relied on them often in our own startup as a key reference. Please keep posting in the series!

  1. 1 Product planning series: who, what, why, how « Startup Musings Trackback on April 12, 2011 at 10:15 pm
  2. 2 Product planning series: Staffing for success « Startup Musings Trackback on April 13, 2011 at 8:12 pm
  3. 3 Product Planning Series: Project Management « Startup Musings Trackback on April 28, 2011 at 6:37 am
  4. 4 Product Planning Series: From use cases to storyboards « Startup Musings Trackback on June 18, 2011 at 10:02 pm
  5. 5 Product Planning Series: Requirements « Startup Musings Trackback on August 9, 2011 at 6:41 am
  6. 6 Product Planning Series: From use cases to storyboards | UX Apprentice Trackback on December 20, 2011 at 1:59 am
  7. 7 Product Planning Series: Information Architecture, Flowcharts and Wireframes « Startup Musings Trackback on January 8, 2012 at 8:24 pm
  8. 8 Product Planning Series: Information Architecture, Flowcharts and … | The Architecture Planning Trackback on January 8, 2012 at 11:48 pm

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: