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 engage in the product planning and execution activities to 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: