Exoventure Associates visit Kiev, Ukraine
"The hardest decision
is to determine what to exclude from the first version of your product. You need to really figure out what the minimum feature set is that a customer needs…and no more!"

Micki Seibel

Building the Right Product at the Right Time…Quickly

Micki Seibel, April 26, 2010

I’m a product veteran of both start-up and large hi-tech companies. Over the years, I’ve worked with product teams that use varying development methodologies—all of which have their pluses and minuses. Regardless of which methodology you prefer, there are three key lessons that that will help any technology team to quickly build the right product at the right time.

Lesson #1: It's worth the time to spec it out.
First, take the time to figure out the optimal path a customer will take with your product. For example, at children’s online game service SmartyCard, we drew up on a whiteboard the steps that it would take for a parent to register with the site. We stepped through the experience as if we were parents and filled out each field correctly. Next, figure out where that path will go wrong and determine how you are going to handle the issues. The mistake that many teams make is that they do not do this BEFORE engineers start building the product. You will save precious development time and avoid having hours or days of downtime if the solution is ready from the start. This way, your development team can keep making progress toward finishing the product and not have to stop to get clarity or wait for business decisions to be made. For example, with our parent registration process, Federal law requires that we first ask for a birth-date to determine if the customer trying to register is, in fact, an adult. What if a child is trying to use this registration process (and we’re collecting information from a minor in violation of federal law)? Not only did we need to make product decisions about how to handle this corner case, it also involved making decisions about our site’s privacy policy and how much legal risk we can afford to assume.

Many technology teams—especially early stage start-ups developing the first version of the product—just start writing code or building a product without a plan. They often mistake this as prototyping. Sure, they have a vision for the product, but a vision is not a spec that turns over every corner case and tells you how to deal with it. Most times, the result is a lot of wasted time, several deadends, and feature creep. Time is lost while meetings are held to make business, policy, and product decisions. Don’t mistake action for progress. “Spec” does not have to mean a novel written by a person whose title is Product Manager. A Spec can be as lightweight as drawing it out on a whiteboard or a more formally written document depending on your preference. The point is to collaboratively make a plan for exactly what is being built before the building begins. This actually reduces development time.

Lesson #2: Have a customer-centric mindset.
Once you have a product idea, run it by a dozen people that fit your target customer. Once you have a spec defined (see Lesson #1), show specifics or samples to target customers. Choose people that really are target customers, and not just likeminded friends. Seek out people who will disagree with your ideas. It’s better that this group find the holes in your product then a future, paying customer. At each step, validate and incorporate feedback from real customers. There are loads of whitepapers and articles on the subject of user testing. I won’t re-hash them here.

Validating with customers, however, goes beyond merely showing prototypes and getting feedback on features. There is a customer-centric mindset that you need to embrace that should manifest itself in everything your team does. Being customer- or user-centric means that every decision is made thinking about how it affects the customer. The customer should be front and center in everything you do. This even includes instrumenting your product to capture and analyze feedback. For example, our children’s game service, SmartyCard, wasn’t ready for launch until we also had the tools and metrics in place to analyze if kids found our games and activities engaging—e.g. how many activities did a child play, how many minutes per activity did they spend, and how many total minutes did they play.

Lesson #3: Build the best Phase 1 (and know who decides what’s not in Phase 1).
The hardest decision is to determine what to exclude from the first version of your product. You need to really figure out what the minimum feature set is that a customer needs…and no more! Focus on the right, small, well-defined feature set. This enables you to get something in the hands of real customers faster (with real customer input and real usage—see Lesson #2). Besides, real customer usage is the best way to prioritize additional features and add-on products.

Of course, not everyone on the team will agree on that minimum feature set. Even in a customer-centric team, there may be contradictory feedback from real customers. There needs to be someone who is appointed the decision maker—whether it’s a Product Manager, the CEO or co-founder, or someone else. Someone will have to make these hard and final decisions, and your team needs to know when that decision is no longer up for debate.

About the Author
With over 14 years of product management experience, Micki Seibel is a veteran of Silicon Valley start-ups. Micki was the Vice President of Product & Customer Experience at SmartyCard, a children’s game start-up. She was the Director of Product & User Experience for the launch of apartment search site, MyNewPlace, and she has held executive and senior management positions with eBay, Ask Jeeves, Netscape, and Intel.

Sound Off | Contact | Exoventure Home

© 2009 Exoventure Associates, LLC, Exoventure is a trademark of Exoventure Associates, LLC.
All rights reserved.