This week you will review all that you have learned from your customer research, re-look at how you have defined your Minimum Viable Product (MVP), and reframe your definition of the solution.
Before we begin: Check out Module 3 and other resources
Following are some resources that will help you accelerate your progress this week.
- Be sure to complete your weekly retrospective and planning ritual. This is an important weekly self-accountability practice that will help you stay on track.
- The first part of Self-Guided Learning Center, Module 3 of the learning center is live! This module on building a differentiable solution covers three key topics that is all about the Minimum Viable Product (MVP): Defining, building, and testing your MVP. We invite you to browse the first section: “Defining the MVP”, as that is the topic of this update.
- Knowledgebase section on Product Management: This section of our searchable knowledgebase provides answers to how you might define your product – especially if it is a software solution.
Why you should revisit your product definition
Venture creation and product design and development are both iterative processes. When you get started, you have an idea of the target market and customer, the problems they face and the solution you will build to solve their problems. As you go into the field and talk to humans, each day you learn more about the market and customer and this gives you new insights about how you might solve their problems with a solution that is different and better than the alternative.
Sometimes these insights help you fine tune your approach. Other times, your insight might be so profound that you may need to pivot away from an approach to the solution altogether. This is why you should always be checking your solution against what you now know about your market and customer.
Defining your Minimum Viable Product (MVP)
In the olden days, product managers spend months, sometimes years, conducting research and generating thick (printed) documents that fully outline the business case (in a Market Requirements Document, or MRD), the proposed solution and use cases and high level product specification (in a Product Requirements Document, or PRD), and a full suite of Functional Specifications that detail the form and function of every single feature down to the punctuation in the user guide.
This is not how products are defined anymore. It is way too slow and cumbersome. A far better way is to use the MVP mentality to create minimum viable documentation. Artifacts generated help you communicate your product vision and provide enough information to guide product design and development (topics to be covered in the next update), but not so much that it overconstrains your team to develop overdesigned features that may not survive first touch with a real customer.
Following is a list of common artifacts generated in the process of defining a product. Read more in Module 3 of the Learning Center, download templates from our resources folders on Google Drive, or look for answers to common questions in our searchable knowledgebase.
- User Persona(s)
- High level product specifications (one page)
- Workflows and storyboards (user centric)
- User stories (user centric)
- Competitive 2×2 – user perspective
- Competitve 2×2 – industry perspective
- Moore’s Positioning Statement
On your competitive advantage
Many entrepreneurs get spooked when they find a competitor that is offering a similar solution to what they are offering. We have a bit of a different view on that. First of all: There are very few ideas that nobody has tried before. Apple’s iPod was not the first MP3 player. The company that wins in a particular market is one that truly understands their customer, solves their problems completely, and executes excellently. Being first is not necessarily a good thing. What the competition is doing should not drive your strategy – your “why”, your understanding of your target market and customer and their pain points, coupled with the specific skills and assets you bring the table should inform what you do instead.
That said, it is important to be able to understand what else is going on in your market from two lenses: the customer lens and the industry lens. You need to understand what the customer’s top priorities are, and therefore, how you might position your solution to be different and better than their current alternatives. You also need to understand the industry landscape and the types of solutions there are, as well as their price points and go to market strategy as there are lessons learned on the successes and failures of incumbent players that can inform you as you craft an implementation strategy.
Contemplating problem-solution fit
The last thing you should be thinking about this week is whether you are on track to arrive at problem-solution fit. In early venture creation, you have quite a bit of flexibility on the solution. This is a great week to synthesize everything you know about the problem you are solving and the customer you are solving it for, and do a sanity check on whether your solution logically and effectively solves this problem.
There are two tools we recommend for this: The Lean Canvas (which you should be updating weekly anyways), and the Moore’s Positioning Statement. Fill these out and if the fit doesn’t feel right – go back into the field and talk to humans, and let the data guide you as you iterate. Good problem-solution fit is the basis of a successful product, which is a necessary (but not sufficient) solution for a successful venture. Good luck!
Thank you all,
Tina, Elaine, Adolfo and the Tufts Entrepreneurship Center team
