NOTE: I spent much of 2015 learning more about product development from conferences, books, blog posts etc. Among the many sources I am indebted to, for this specific post I want to call out and thank Melissa Perry, Jon Kolko, and Boon Sheridan.
1. A new product’s problem/solution fit considers what problem exists and how/why we would want to solve it. Key questions for determining a good problem/solution fit are:
- What problem are we solving?
- Who are we solving it for?
- Why are we solving it?
- How are we solving it?
- What does solving it mean for our company?
- What are we doing to realize our solution?
2. And then there’s the market/solution fit—the perfect solution to a problem is useless if customers don’t want to buy it. Key questions for determining a good market/solution fit are:
- Is our solution repeatable?
- Is our solution scalable?
- Have we eliminated friction from the conversion process?
- Have we factored user gratification/retention into our customer journey?
- What are our customer acquisition channels?
- What are our specific metrics for defining success?
3. Some foundational concepts for product development are:
- The customer journey guides product conception and execution
- Our solution plans for the entire customer journey
- We explicitly plan and design for each individual touchpoint within that customer journey—from initial product research, to eventual purchase, to customer service and product maintenance
- Our solution responds to both customer and business needs
- We validate our solution with both business stakeholders and customers
4. What are some assumptions we should be aware of—and avoid?
- We already know what our customers want—we just need to build it
- We’ve got to create this product since our competitors have one
- We can begin by defining the solution instead of the problem to be solved
(Can lead to creating solutions without corresponding problems) - Customers have as much knowledge as subject matter experts
- Customers are willing to spend as much time with our product as we want them to
- We can use unvalidated data to guide product development
(The perception that “everyone wants this” often masks the reality that it’s just a few loud opinions and isn’t broadly desired) - We should develop the first solution we come up with
(It’s usually not the best possible solution)
5. Some specific recommendations for product development are:
- Create the lowest-possible fidelity wireframes to prototype the smallest-possible product iterations
- Start product planning with the small viewport and add progressive enhancements to larger views
- Plan for content flow, not screen flow—expect to chunk the experience differently for different views
- Utilize design systems where possible—don’t continually reinvent the wheel
- Explicitly plan and design for errors—they will happen! Customer experiences that have carefully-considered, helpful and informative error states inspire customer confidence
- Ensure the product’s future-friendliness via flexible design and code
6. Create a Feature Request Form to help colleagues prioritize ideas:
- What feature would you like to build?
- What KPI will this feature change? By how much?
- Is there any other value for this change?
- What is the business priority?
- Is this dependent on other changes that have yet to be made?
- Why is this a problem we can and want to solve?
6. Tips for “failing fast” and learning:
- Don’t overcommit to the first solution; let it go if it doesn’t prove viable
- Test very early, very quickly, very cheaply
- Create small, data-driven experiments to validate interest:
interview customers / make a landing page / create a lo-fi prototype, to test:- Do users have this problem?
- Are they interested in our solution?
- Are they interested in any solution at all?
- Tests that fail to prove interest may reveal actual customer problems
- The risk of continuing to work on a bad idea gets higher over time
- Customers don’t understand/care about product iterations. The risk of launching a weak product can be huge—unsatisified customers won’t stick around for your v2
7. Start the development process one piece at a time:
- Start with small, meaningful improvements (existing products)
- Start with something small as an introduction (new products)
- Get some small wins under your belt while establishing team cadence
- This also creates a platform for growth—it’s impossible to learn everything in advance of building a new, complicated product
- The team will learn throughout the process—not just at the end
- The team will receive faster, more continual recognition for achievements
- Rapid testing along the way helps establish criteria for testing the final product
