The Startup Method: A 6-step Process for New Feature Development

This is the last article in a three-part series on building products for critical mass. Part I discusses why every startup needs a story. Part II details how to translate a story into a product flow. In this article, I’ll discuss how you can take a product and increment toward success.

The first version of a product is months of assumptions based on your intuition for what you think it should look like. Unfortunately, there’s almost always a gap between what you’ve built and what users want, and the majority of product launches result in users signing up and never coming back. This is common, and now you’re faced with an uncertainty about how to advance.

Of the startups I’ve helped launch, the most difficult task has always been to take an alpha product and iterate until it begins to find traction. Twitter, Pinterest, and hundreds of other successful startups had rough beginnings. The founders built success through trial and error. You’ve built something, but users aren’t signing up in droves. Now what?

Software companies with millions of users and a mature product line have an easy time knowing what to build next — users are sending in hundreds of feature suggestions, data points are easily measured, A/B tests are conducted often, and the team slowly increments the product forward with minimal risk. Pre-product/market-fit startups have a more difficult task with little data to draw upon, and the situation is analogous to an unrelated industry that also deals with a field of unknowns: chemistry.

Drug companies research cures for decades in search of answers and employ a framework most of us will find quite familiar: the Scientific Method. The Scientific Method is a framework for dealing with uncertainty and can be applied to both the startup exploration phase and new feature development. I’ve adapted this framework to startups and have aptly named it The Startup Method:

Whether you’re a chemist in the lab or an entrepreneur building a product, utilizing a repeatable framework with a fixed process guides you to knowing what step to take next when you don’t know the answer.

Step 1: Propose a user story
A construction worker sees a house as wood, nails, and a foundation, but a homeowner sees the same house as a place for privacy, dry shelter, and protection. Likewise, designers and engineers often view their product from the perspective of a builder and instead need to view it as a user. Writing the proposed change as a user story helps frame the task to keep it user-facing. Switching your Javascript framework from Backbone.js to Angular.js, for example, would have little impact on the user and needs to be prioritized appropriately.

Format: As a <type of user>, I want to <do something> so that <some value is created>.
Example: As a new user, I want to be able to find my Facebook friends on the website so that I can see more relevant activity in my feed.

User stories can result in additions, subtractions, or modifications to the product. As I discussed in Part I, building an extra feature can be a step backward for the user, while removing a feature can be a step forward. Each story should be a significant change to the product as well as an opportunity to explore macro changes that might help the product reach its absolute maximum.

Step 2: Talk to users

Sometimes when ordering a meal at a restaurant, I’ll wonder if a dish is any good. Asking the waiter if he recommends the ravioli, I might hear him say, “Of course. It’s my favorite on the menu!” A different approach would be to ask the waiter which of the three options I’m considering is the best, and his recommendation might change. It turns out he avoids the ravioli and instead prefers the salmon.

When you’re asking users for feedback, it’s common to receive false positives because they often don’t know what they want, and they’re not involved in the actual work it would take to make the change. Presenting multiple user stories yields more accurate responses. Users have a chance to prioritize what matters to them most.

You ask: “Would you like a faster website or the ability to find your Facebook friends on the product?”
User response: “A faster website would be nice, but I’d much rather be able to find my Facebook friends on your product”.

It turns out your website wasn’t as slow as you thought it was and instead users would prefer a new feature. Gathering user input is crucial, but it’s only helpful if the feedback is accurate.

Step 3: Prototype the new change
You’ve found a feature that users want; now let’s spend the next few weeks building it right? As soon as you implement said feature, you’ll realize how it could be better and will have to spend another few weeks on development. Designers and engineers are natural builders, and it’s easy to jump right into Photoshop or TextMate. Instead, iterate upon a wireframe or prototype to easily double the speed of progress.

I used to cringe when I would hear recommendations about gathering user feedback from prototypes, but software has improved leaps and bounds over low-fidelity options, such as Basalmiq or Omnigraffle. High-fidelity tools, such as Indigo Studio, Axure, and Invision, allow rich prototyping with animations, input forms, and even dynamic data. Prototypes can easily replace a working product and cut out the building process while you’re testing new ideas.

Step 4: Conduct a user test

Once a wireframe or prototype has been formed, it’s time to test it with people and gather feedback. Reaching out to your user base is the best way to gather feedback for user stories aimed at existing users. For new users, it’s a more difficult task. A common strategy is to “get out of the building” and engage in guerrilla user testing. I’ve always found approaching random people in coffee shops uncomfortable and bothersome, particularly if you’re outside of tech meccas like Silicon Valley or New York City where it’s uncommon.

A more scalable method is to use a remote testing service, such as UserTesting or Userlytics. Five tests will give you enough data to provide conclusive analysis for a proposed user story. Scheduling tests regularly ensures constant feedback so that you stay calibrated with how users view your product. It’s too late to get feedback after the feature has been implemented. You’ll end of wasting time on iterations that could have been avoided.

Step 5: Decide whether to implement

Deciding whether to implement a feature is the crux of this process. It’s much harder to decide against implementing an idea you’ve come up with because it often feels as if you’ve wasted your time and failed. There’s also a common misconception: unless you’re building, you aren’t making any progress. This couldn’t be further from the truth. Apple’s recent advertising campaign explains why: “There are 1000 no’s for every yes.”

Another challenge is when you’re excited about a feature and you’ve received great feedback from users, but it might not be the right feature to implement right now. Apple created, prototyped, and was really excited about the iPad. However, the team knew it wasn’t ready for the market. They put the product back on the shelf and first released the iPhone. Their patience and long-term thinking were critical for both products becoming the success that they are today.

During each phase of a startup, there is only one metric that matters. An early-stage startup is typically focused on growth, while later stage startups might be focused on retention and revenue. Determining which metric your startup is focused on right now helps prioritize whether it’s the right time to implement a feature. Features that have a positive effect on this one metric are the only ones that should be implemented. You’ll come across great features you’ll want to implement, but it might be best to wait until the product has reached the next phase.

Step 6: Build and implement

With the golden age of design upon us, users have the highest of expectations when it comes to product launches. You’ll certainly hear complaints if you don’t have beautiful, retina-optimized graphics, an expensive demo video, and a polished, responsive website that supports Google Glass. However, iteration is the antithesis of perfection. It’s important to avoid such details until you’ve found a strong signal from users that you’re on the right track. Only when you start to see users coming back to the product should refinement, polish, and growth become priorities.

During the exploration phase, keeping a small sample size is crucial for allowing quick development. Supporting the smallest viable user base encourages the freedom to make drastic changes on a regular basis, remove features, support only a few browsers, and deal with minimal customer support issues.

Thanks for following along with this series on creating a successful startup and I’ll be publishing more articles in the coming months. Follow me on Twitter to be the first to know when new articles are published, and feel free to make suggestions on what you’d like see published next!