Staying Innovative as Your Business Grows (Part Two)
By George Bilbrey
Last month, as part of the Online Entrepreneur column, I shared some of Return Path’s organizational techniques we use to stay innovative as we grow. In this article, I’ll talk about the process we’re using in our product management-and-development teams to stay innovative.
The Innovation Process at Return Path
As we grew bigger, we decided to formalize our process for bringing new products to market. In our early days we brought a lot of new products to market with less formal process but also with more limited resources. We did well innovating one product at a time without that kind of process largely because we had a group of experienced team members. As the team grew, we knew we had to be more systematic about how we innovated to get less experienced product managers and developers up to speed and having an impact quickly.
We had a few key objectives when designing the process:
• We wanted to fail fast - We had a lot of new product ideas that seemed like good ones. We wanted a process that allowed us to quickly determine which ideas were actually good.
• We wanted to get substantial customer feedback into the process early - We’d always involved clients in new product decisions, but generally only at the “concept” phase. So we’d ask something like “Would you like it if we could do this thing for you?” which often elicited a “Sure, sounds cool.” And then we’d go off and build it. We wanted a process that instead would let us get feedback on features, function, service levels and pricing as we were going so we could modify and adjust what we were building based on that iterative feedback.
• We wanted to make sure we could sell what we could build before we spent a lot of time building it - We’d had a few “build it and they will come” projects in the past where the customers didn’t come. This is where the ongoing feedback was crucial.
We stole a lot of our process from some of the leading thinkers in the “Lean Startup” space – particularly Gary Blanks’ Four Steps to the Epiphany and Randy Komisar’s Getting to Plan B. The still-evolving process we developed has four stages:
Stage 1: Confirm Need
• Understand economic value and size of problem through intense client Interaction
• Briefly define the size of opportunity and rough feasibility estimate – maybe with basic mockups
• Key Question: Is the need valid? If yes, go on. If no, abandon project or re-work the value proposition.
Stage 2: Develop Concept
• Create a high fidelity prototype of product and have clients review both concept and pricing model
• Where applicable, use data analysis to test feasibility of product concept
• Draft a more detailed estimate of effort and attractiveness, basically a business model
• Key Question: Is the concept Valid? If yes, go on. If no, abandon project.
Stage 3: Pilot
• Build "minimum viable product" and sell (or free beta test with agreed to post beta price) with intense client interaction and feedback
• Develop a marketing and sales approach
• Develop a support approach
• Update the business model with incremental investment requirements
• Preparation of data for case studies
• Key Question: Is project feasible? If yes, go on. If no, abandon project or go back to an earlier stage and re-work the concept.
Stage 4: Full Development and Launch
• Take client feedback from Pilot and apply to General Availability product
• Create support tools required
• Create sales collateral, white papers, lead generation programs, case studies and PR plan.
• Train internal teams to sell and service.
• Update business model with incremental investment required
• Go forth and prosper
There are a several things to note about this process that we’ve found to be particularly useful:
• A high fidelity prototype is the key to getting great customer feedback – You get more quality feedback when you show them something that looks like the envisioned end product than talking to them about the concept. Our prototypes are not functional (they don’t pull from the databases that sit behind them) but are very realistic HTML mockups of most products.
• Selling the minimum viable product (MVP) is where the rubber meets the road – We have learned the most about salability and support requirements of new products by building an MVP product and trying to sell it.
• Test “What must be true?” during the “Develop Concept” and “Pilot Phases” – When you start developing a new product, you need to know the high risk things that must be true (e.g., if you’re planning to sell through a channel, the channel must be willing and able to sell). We make a list of those things that must be true and track those in weekly team meetings.
• This is a very cross functional process and should have a dedicated team – This kind of work cannot be done off the side of your desk. The team needs to be focused just on the new product.
While not without bumps, our team has found this process very successful in allowing us to stay nimble even as we become a much larger organization. As I mentioned in Part 1, our goal is really to leverage the strengths of a big company while not losing the many advantages of smaller, more flexible organizations.
About the Author: George Bilbrey is president of email deliverability and security firm Return Path. He writes the Online Entrepreneur with his colleagues Matt Blumberg and Jack Sinclair. Together they cover how to approach the business of email marketing, thoughts on the future of email and other digital technologies, and more general articles on company-building in the online industry – all from the perspective of an entrepreneur.