What is the best way to determine the minimum set of features for a MVP?

Even with a great idea, it's still crucial to comprehend the customers' problem being addressed. We should also assess how it is being currently tackled. Optimizing for the fastest time-to-market, a balance between value-added and effort can be struck for individual product features, which results in a minimum set of features. Then engineering can start work, but in parallel the solution should be tested cheaply (via prototypes or even mock-ups) with the main target customers. The solution should be adapted mid-term (if the feedback from the testing is really critical). There could be some wastage (or sometimes a lot), but it accelerates time-to-market avoiding analysis-paralysis.

Focus on customer pain before you think about the solution. Go narrow, and pick one to solve. Ideally this should pain should be felt by a single, easy-to-identify audience.

Empathizing with the customers lies at the heart of finding a deep pain point. Map it on "importance" (Y axis) and "satisfaction" (x axis) graph. Target the upper left quadrant (high importance, low satisfaction). For customer discovery, leverage the following tools to empathize: - Interview: ask them about challenges they face, how they currently solve it , what's not working, how they discovered the current solution. - Day in life of: walk a mile in their shoes by becoming a customer or shadowing them. - Social listening - see what people are complaining about on Reddit, FB, reviews etc. This will help you find your right target audience, identify channels to reach them, create a resonating message, and co-design a solution with them.

An MVP is about a narrow focus more than a shallow deliver of functionality, so focusing on the core value proposition is key. I personally advise teams to focus on defining the narrowest version of your product. This often sits at the intersection of prioritizing features and benefits based on the table stakes, differentiators, and delights with a single use case or Job to be Done. This creates a narrow slice of features and benefits that describe a core value proposition you can deliver to customers.

The core value proposition in the context of an MVP is the simplest solution that benefits your customer. One that you can build on or enhance in subsequent releases. So, given a solution, what features can you remove before what remains no longer benefits your customer?

MVP scope is shaped by both business model (B2C/B2B) and product nature (pill/vitamin). B2B Pill: Solves immediate business pain. E.g., Stripe's API streamlined payment processing. B2C Pill: Addresses urgent consumer needs. E.g., MinuDoc offered a simple doctor-call list. B2C Vitamin: Elevates daily consumer experience. E.g., Instagram began as a filtered photo-sharing app. B2B Vitamin: Long-term business operation improvement. E.g., Slack introduced an intuitive chat interface, redefining team communication.

To identify set of features, tools like Impact Mapping and Story Mapping have been very useful. And then prioritizing those using techniques like WSJF, RICE and Kano.

Always create a sheet of assumptions and things we consider base reality and always create contingency plans for base reality while getting rid of all the assumptions by either talking to the customer or analysing other products in the market.

Beyond assessing impact and uncertainty, engage with developers, scrum masters, UX designers, and product owners to gauge their bandwidth. Collaboratively prioritize tasks that yield the highest impact. In Product Management, being a valuable resource to your team is as crucial as decision-making.

In 99% of cases, MVPs shouldn't take more than 8 weeks to build. If you're looking at a longer timeframe then you're likely: 1. Building for scale you don't need yet 2. Solving too many pain points 3. Targeting an audience that's too wide

Don't guess, test! Before you "build" anything, you must EXPERIMENT to validate everything above! From lo-fi to hi-fi, this can take the shape of: -Putting a pitch deck or a glossy brochure with an offer in front of a customer to gather feedback. (Test customer problem, pricing) -Running a social media ad linking to a landing page to gather registrations. (Test value prop, business model) -Creating a very realistic, no-code prototype of the key experiences of your product and testing it with a small group of users. (test features) -Creating a fully-fledged, no-code version of the product (test useability)

Before building, my favorite (and least) favorite question to ask is: What can we cut to get this out faster? The tighter the product, the faster you'll get to the validation phase. And yes, if you love what you're building, this part is painful.

Pretotyping could be a good option here - quickly test things before really building anything. Write hypotheses that will be validated or invalidated - set three to four, each with measurable metrics. Be agile and iterate when needed - listen to customer feedback or review how the MVP is being used. It's OK to fail - although technically you succeeded in invalidating the hypotheses. This is the whole point - if it didn't work you haven't wasted time and money building it. If it needs to be tweaked or pivoted, you can do that too.

Imagine walking through a dense forest with a single beam of sunlight piercing the canopy. Your MVP is like that beam of light, illuminating just enough to reveal the path. It's not the entire forest, but it guides you forward. As you take each step, you discover what's essential, what the forest truly offers. With your MVP, you embark on a thrilling journey, uncovering the hidden treasures of user needs. Along the way, you shape your product like an artisan crafting a masterpiece. And when you emerge from the forest, your MVP has transformed into a product that not only serves but enchants.

Drawing from my days as a product specialist, the Feature Voting Workshop was transformative for MVP development. Once, while ideating a new app, we invited potential users, stakeholders, and team members to a session. Everyone proposed features, and then each person had a set number of “votes” to allocate. The features gathering the most votes became our MVP priorities. This hands-on, democratic approach provided a real-world gauge of what was truly essential to our users. Beyond just internal assessments, actively involving your audience in feature selection can give you invaluable insights, ensuring your MVP addresses genuine needs.