Product Planning Series: Requirements

This is the sixth post in my Product Planning Series.

The mere word “requirements” can make a lot of startup people wince. It conjures up the bad old days where folks spend months developing an MRD, PRD and a Functional Specification. It brings up images of Stage-Gate and classic Waterfall processes.

There are situations where big long planning documents make sense.   For example, if you are developing a medical device that needs to go through the 5(10)k process, you really have very little choice.  You have to go by the medical devices handbook which pretty much stipulates that you need to write all those documents and place them under a document control process.

However, in a startup situation, where you really don’t know if your problem, solution, and business model will jive with customers and users, overinvesting in planning documents just leads to lost time and productivity.  It also sends the wrong message to the team: instead of being open minded and work closely with customers to define the product and the business model, you are making up too much of it in the office. By the time the big MRD is written the world has already changed and the requirements could be obsolete.

I am against over-investing in requirements documents. However I am even more against not writing anything down and relying on tribal knowledge to implement a solution. That works if there are, like, 2 people in a startup. When you have more than 3 or 4 people working on the same thing, communications becomes very important. Working in a fast paced startup where new data comes in constantly is not an excuse to punt on basic common sense.  Good team communications practice begats good project execution, which will increase the probability that your product will do what you want it to do in the marketplace.  By the way, this goes for hardware AND software.  Even an agile process needs a holistic view of the end goal.

Here are some requirements do’s and don’ts in a startup setting.

DO

• Write SOMETHING down
• Get buy-in from ALL STAKEHOLDERS.
• Be practical and specific. Leave it loose at your own risk.
• Build a top level project plan that identifies key tasks, milestones and interdependencies
• Develop a lightweight 2 year roadmap

DON’T

• Start building anything without buy-in
• Write a 100 Page MRD
• Overspecify details on each feature in classic Waterfall fashion
• Build a 5 year product roadmap with a great deal of detail

At the end of the day, for a development team to be productive, they really don’t need big long documents to describe everything. They just need a few slides on a few topics.  Here are the topics that I find useful to write down for the team. A lot of this stuff should be available for free, from the business case and who/what/why/when discussions.  Some of it is technical – like a lightweight description of the MVP.

• Clear description of the market problem that is being solved
• “Elevator pitch” of the solution (preferably with images)
• Description / analysis of first target segment
• Buyer and User Personas
• Detailed storyboards on top 1-3 typical workflows
• Specific examples for details encountered in each workflow
• Considerations for human factors / human cognition
• Top level design directions to be followed by product design team
• Lightweight functional description of minimum viable product (MVP)
• Quick and dirty 2 year product roadmap
• Any external business drivers (e.g. trade shows, funding runway, etc.)

The most important thing is to do the thinking and research that will support the materials presented in these types of documents. The second most important thing is not to overthink things when you write them down.  Use the minimum possible number of pages to convey the information – don’t overinvest.  That way you will not feel too badly if customer development tells you something new and you have to trash some of these documents and write them over.

Product planning series: who, what, why, how

This is the second post of my Product Planning series (which uses a new web app as an example to illustrate how you go about planning the release of a new product or service.)

In my last post I outlined some of the questions that you should ask to establish a business case for your new product or service. Once that’s done, it’s time to define who you are building the product for and the problems they face, what your proposed solution looks like, why you think it is better than anything else out there, and how your solution will work to solve these customer problems.

Who
The first question some people ask is: why segment and target? If one does a wonderful job with product development, shouldn’t the product sell to anyone who might find a use for it? My answer is this: it is not possible to develop a wonderful product without knowing who you are designing it for.

Let’s say our web based B2C consumer SaaS offering is an educational site for children that focuses on advancing the musical education of kids who are learning an instrument.

Right away we can see that the buyer (a parent, grandparent or teacher) is different from the user (a student). You will need to build a buyer persona and a user persona. The buyer (parent) wants the child to learn. The user (child) just wants to have fun. To be successful the product must both educate, to meet the needs of the buyer, and entertain, to satisfy the wants and expectations of the user and to ensure stickiness and compliance in product usage.

If the word “persona” is new to you, Pragmatic Marketing has an excellent article explaining the persona concept, and Scott Sehlhorst has a great article on this topic. You can also consult my post on using ethnographic techniques to develop personas.

The purpose of developing the persona is to use the target buyer and user to help decide what to build and how to present it. What age group are we targeting – do you need to cater to the pre-reading crowd? How high do we go in the age bracket? These affect the user interface and use cases because clearly a 15 year old violinist playing first violin in a youth orchestra has vastly different needs and wants than a 5 year old violin novice working on basic bowing techniques.

Persona development goes far beyond demographic information and goes deep into situational scenarios. What is it like living in the households of these music students? What is their daily schedule? How long do they spend on music practice each night, and for how many nights a week? When do they practice music? How involved is the parent? Are they distracted by their siblings? What parts are hard to learn? What are the objectives of the child and what problems does he or she face? What are the objectives of the parents and how do they measure their child’s success?

A good persona provides demographic and psychographic information, as well as additional information about the attitudes and motivations of the persona in the area of product use. It is well worth the initial investment to develop a good set of personas, then clearly delineate the problems they face. It will help make development more efficient down the line and help you develop a great user experience that is tailor made to your target end users.

What
Once the buyer and user personas are defined, and their problems are well understood, it’s time to figure out what the solution to these problems might look like. For example, it is very hard to motivate a young child to learn all those pesky Italian musical terms. Perhaps an on line memory game might help them remember those terms. Another example is that the child may need to work on posture. Perhaps a video feature that allows the parent to take a video with their cell phone, then upload to a server and share it privately with the teacher might help. A third example is that the child has forgotten the correct technique 3 days after the teacher demonstrated it. A video snippet of the lesson might just do the trick. And having this all in one place encourages usage and compliance.

As a product team comes up with solutions, there are invariably way more ideas than what would fit in a desired timeline. Here is where the persona will be useful: the product team can use the persona to help them imagine what is of the most use to those personas, and develop a release roadmap where features that deliver the most benefits and value are released first, followed by other features that either broaden the offering or offer secondary benefits.

Why
Many wise product and startup people, including the folks at Y-Combinator, have commented on the need to focus on the customer, not the competition. This is very true. However that doesn’t mean you get to punt on doing a thorough competitive analysis to understand exactly what is out there in the market. This helps you in several ways:

• You can check to see if your solution really solves an unmet need. If to your chagrin you find something that solves the problem quite well, it’s better to know sooner than later so you can pivot to solve a different problem that REALLY represents unmet needs.
• You can learn from the successes and failure of other people who were in the market before you.

With a good understanding of the competition you are well poised to articulate your competitive advantage which is necessary for developing an actionable and meaningful positioning statement.

How
Interestingly, many technology startups start with the “how” as the basic premise for starting a company. Someone comes up with a brave new technology, develops a prototype for it, gets it to work, falls in love with it, then sets off starting a company with a field-of-dreams business plan.

That works sometimes if the technology is really world shattering. In consumer SaaS, the technology itself is sometimes commodity software. So for those types of products, the “how” comes only after having figured out the who, what and why. The “how” is concerned with how to actually implement the solution. For this example, you would pick the technology platform to develop your new site on – fielding considerations such as open source versus proprietary platforms (my vote: Open source), database of choice (I like MySql), programming platform (for complex web apps: Java EE back end with Javascript or HTML5 front end; for quick hacks, I like Ruby on Rails). You will need to make decisions early on about hosting and server care and feeding too: certain platforms bring a hefty server side license fee and you will need to account for it in your projected server fees and expenses.

Once the platform is picked, you can now work on defining and designing the product in detail, staffing up for success, and executing the plan to bring your offering to market in the desired timeframe.

A year in review

As the year draws to a close, it’s time to reflect upon the good, the bad and the ugly in this year.

• We did a really cool segmentation and ethnography project that helped define buyer and user personas. That was great fun.
• We did a bunch of pricing research on the cheap, but the results were inconclusive.  Probably should have hired professionals to do this (a casualty of working for cash-strapped startups).
• We built a strong, diversified, talented and productive software team.  This makes me feel like a million bucks.
• Said team figured out how to develop and self-host a scalable web based application. That felt great.
• We launched a new iPhone App.  That felt great.
• We had several intense “Oh Crap” moments. That felt crappy but all’s well that ended well after we fixed what’s broken.
• We launched a massive new project with a ridiculously aggressive timeline. That felt scary.
• We are miraculously on schedule 1.5 months into said aggressive timeline. That felt great (even though I still come close to passing out each time I visualize my 390 line Gantt chart in my head.)

At the end of the day, everything that was achieved at work was achieved because we put together a fantastic team of trained assasins who are super good at their jobs, yet flexible enough to adapt themselves to the rapidly changing needs in a startup environment.  I’m very proud of my team and all their achievements.  They rock!

Customer research series

I am doing a bunch of product discovery and product usage research at work.  This is what I love most: getting out of the office and talking to customers.   I decided to start a series on this topic since it is so much fun and so strategic.

For this series, I am using the word “customer” broadly – to include prospects as well as existing customers who have already purchased a product, and to include both buyers and end users.  This is because there is no common definition of the word “customer” and this series addresses all of the above constituencies.  I will clarify where necessary in specific posts.

Here is a tentative menu of posts.  It’s a work in progress.  Any suggestions would be greatly appreciated!

1. Why do qualitative research?
2. From personas to functional specifications
3. Asking the right questions of the right people
4. Common ethnographic techniques
5. Using detailed interviews to build personas
6. Focus groups vs. roundtable discussions
7. Usability research in the lab
8. Beta Programs
9. On-line surveys
10. Customer Advisory Boards

Does a kick-ass product guarantee success?

Yesterday I read a post on the StartupCFO blog titled “It’s all about product….” It’s a really insightful post about how a kick-ass product is key to startup success.  Being a product person, I would really, really love to be able to agree with his argument that nailing the product, user experience and value proposition is a recipe for success.

Unfortunately, that has simply not been the case in my personal experience.  I can count at least two products that were done right in every conceivable way – end users loved them, usability was wonderful, all that good stuff.  In both cases the products failed miserably.

The first one didn’t fly because for all the success we had in nailing the needs and wants of the end user, we had failed to meet the needs and wants of the sales channels.  This product ended up fighting for attention with another of our own products which cost 10 times as much.  Needless to say, the channels had to protect their own interests first. They kept right on selling the older, costlier product and ignored the new segment that was supposed to get us exponential growth. The product was taken off the market within 18 months and died an uneventful death.

The second one didn’t fly because the company never quite found a business model that worked.   Once again, we focused too much on the needs and wants of end users and nailed everything we could nail, but we failed to focus on the needs and wants of the buyers (huge global entities that moved to a glacial timescale in comparison to our needs).  Eventually all product development ceased while sales continued valiantly to try and figure out some angle to sell this wonderful, wonderful product that end users loved – up until the day when the company closed its doors.

I agree with the author that nailing the product is crucial to success. But much as it pains me to say this, a kick-ass product is at most half the equation.   Kick-ass execution all the way through the whole value chain is the other half.  Success won’t happen without one or the other.

Social networks are dominated by people aged 35-49. That’s GOOD!

I have a friend who keeps laughing at me for hanging out on Twitter.   She tells me it’s passe.  All the kids have abandoned it.  It’s not trendy.  Only older people use it.  And there’s proof: Nielsen says 35-49 year olds dominate everything.

Well, DUH… why does she think I hang out in these places?  I like connecting with fellow Gen Xers.  I get vastly more value out of these networks today, compared to a few years ago, when nobody I knew was on these networks.  I have repressed all memory of life before LinkedIn.  And Twitter has become a fountain of knowledge.  I follow people, businesses and groups, I click links, then I subscribe to the ones I find interesting.  The quality of my Google Reader subscription list has improved 300%.  And I keep tabs on my friends and family, as well as their kids, pets, plants and fancy foodie dinners on Facebook with no effort.  It’s all good.

So the stats are working for me as a consumer.  They are also working for me as a product person making things for people in this and adjacent age brackets. It tells me my buyer and user personas can be reached on these networks, and that I have new tools to reach them and engage with them that were nonexistent 10 or 15 years ago.

This stuff is mainstream now.  So what if the tweens have abandoned Facebook?  I say to everyone in my generation (and beyond): get over the denial, get online and engage!

10 Signs you aren’t developing a Minimum Viable Product

10. You picked an embedded processor that yielded a firmware footprint headroom of 127% for future expandability.

9. Your firmware person often writes innovative features beyond what’s in the spec to harness some of that excess power in your processor.

8. Your product has a custom adaptor for an interchangeable component for which there is no alternative option.

7. You designed your PCB to be modular so you can plug different boards into the main board with nice flex cables. But you only ever sell the main board with the same module plugged in.

6. Your typical end user regularly uses only 7 out of 32 available user interface elements.

5. You invested heavily in a highly original feature that an end user championed. Upon investigation, he was one of 17 who cared  about this feature – out of 13,267 end users.

4. It’s hard to write a tutorial that exercises the full feature set, because 40% of your features don’t fit in the top 3-5 use cases.

3. You keep holding the release because someone keeps coming up with a last minute feature idea that really isn’t that hard to implement.

2. Your idea of product success is to solve some of the problems of all of the people out there, rather than solving all of the problems of some of the people out there.

1. It’s been 4 years since you proved the feasibility of your technology, yet your product is still in development.  And your product has nothing to do with curing cancer or sending humans to Mars.

Is this you? If so, you may want to read this seminal article on Minimum Viable Product by Eric Ries,  followed by this great article on the Minimum Viable Process by Cindy Alvarez. It may help make your product development cycle a little leaner the next time around.