When building a minimum viable product (MVP), there’s a lot to consider. If you’re an expert in the industry, it may be easy to dive in and start planning product features or generating mock-ups right away. While both are great things to do, it’s better for your whole team to start with context.
If you’ve found someone to build the MVP (whether a contractor or technical Co-founder) you will find that there’s some calibration that must happen before good progress can be made.
In my experience, here are some topics to discuss for internal alignment, followed by some thoughts on each:
VISION
A big picture view of what your product will do and why people will care. Creating a basic timeline of product goals (both realistic and hopes/dreams) will help define pace. Everyone should know the product vision, and this isn’t exclusive to just the early stages.
VOCABULARY
A list of common words or ideas that exist in the industry. For example, if we were building a marketing automation product, we will define words such as Lead, Prospect, Contact, List, Segment, Trigger, and Workflow. By defining these terms, you establish a guide of how you talk about your product internally and to customers. It will provide clarity, especially if it is your team’s first foray into the industry.
CURRENT SOLUTION
Before you start talking about how you can make things better, start diagraming (on a whiteboard) how the majority of people are tackling the problem today. Discuss similarities, differences, pain points, and facts. Don’t get caught up talking about specific products -- it’s best to keep the discussion broad. For example, say “CRM” instead of “Salesforce”, unless your product relies on a name brand.
Keep in mind it is possible no software solution exists today, which can lead to fragmented workflows that don’t adhere to standardized best practices. Even so, some similarities generally do exist across different workflows serving the same goal.
Be sure everyone is able to speak to your customers’ existing workflows and goals -- this is a must-have for truly understanding the context of the problem.
HYPOTHESIS AND PROPOSED SOLUTION
Now that you’ve mapped out the problem, the vision, the current process, and the current goals, you can begin to form and test a hypothesis.
Your hypothesis is a statement that you wish to prove. For example, “Our event planning software will help event planners build preference profiles of their clients, resulting in an increase of additional events booked by repeat clients.” With this hypothesis, we know that increasing “additional events booked” is the most important outcome, and that we’ll need an upfront way for the customer to track this goal in our solution.
Talk about how your proposed solution can serve the customers’ goals, and how you can prove your hypothesis. Again, keep your ideas broad (but defined) and your diagrams simple.
---
Starting the discussion with these basic topics may not guarantee perfect internal alignment, but it is a great starting point. Keep the conversations simple to promote natural, rapid iterations.
In the end, internal alignment and shared context leads to informed decision making and better communication. The result is not only a stronger product, but a stronger company as well!
