Was ist der beste Weg, um den Mindestfunktionsumfang für ein MVP zu bestimmen?

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.

The concept around MVP is to "Build-To-Learn" something about Customer and their underlying need before we "Build-To-Earn". So identifying our biggest risk and assumption, and getting those validated through MVP.

A product is a solution to a customer's problem. Or to frame it in job parlance: a customer has a job to do, and they buy products and services to get a “job” done. Pains are the impediments to getting the job done or the cost of not getting the job done. Gains are the benefits of getting the job done. Start with the job, then move on to pains and gains. Alternatively, ask why they need to get the job done or how they might do it. Ask why repeatedly, and ask how repeatedly to explore the problem space. The exercise is called "how-why" laddering.

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?

I look for a MVP to give me a definitive answer on whether the core value proposition provides value to real users. Any development that isn't required to arrive at this answer isn't part of a true MVP. Many (including this AI article) reframe it as "validat[ing] your value proposition." Getting validation is great but if a MVP doesn't validate or invalidate the value prop then it provided no feedback. Ensuring you get a answer, even a rejection of the value prop, is better than no answer at all.

To pinpoint the core value proposition, ask customers and your internal team what immediately springs to mind when presented with the solution. Their initial words reveal the essence of its value.

The product MVP is crucial. It must be solving a big problem/ gap in the market or providing insane value to the user. If the MVP adds value to the user’s experience then one can imagine years of product management would make it a part of one’s life forever.

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.

Validating the feedback for each listed feature is paramount to the job. Obtaining data without distortions and diligently working to eliminate human biases is fundamental. This is the basic level of all product construction, like a building, and the fundament should be exceptionally robust and of the highest quality.

There are 2 parts to this. 1. What you (product owner/business owner) consider as important features. You can get this using any of the Prioritisation frameworks out there. 2. You can ask your early users as to which features fall into which bucket: (i) Must be available (ii) Nice to have (iii) Not necessary Ways to capture this can be: (i) When people signup for waiting list, ask them while capturing their email. (ii) Survey forms for beta users (after soft launch).

I would start this process by outlining the user journey, not via individual core features. If you think in journeys, you're more likely to see which pieces are essential and which are... not.

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.

It's not as straightforward as a basic chart with the most important features, criteria, and unknowns. It's more like a river with multiple flows (many factors at play). For instance, your frontend leader is in the hospital for the next two weeks, and you can't tackle a highly technical task. Meanwhile, your competitors just introduced some cool features last week. Now, you're faced with a choice: should you follow suit or take a different approach? Also, management has some ideas that don't necessarily match the impact or the level of uncertainty involved. This decision will depend on different pieces of information that are considered and sorted based on their significance for the current situation, right here and right now.

Always focus on validating your assumptions. Higher the risk/uncertainty, pay more attention on that assumption and validate it.

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

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.

Use Nocode tools to launch your MVP in few hours / days. Some of the common tools that you can use are Glide, Softr, Bubble etc. that have many readymade templates for most usecases. DO not spend time in coding for MVP, unless its critical for your business's USP ex: deep tech etc.

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.

When defining your Minimum Viable Product (MVP), consider the maturity of the market you're entering - is it a new niche or an already established one? New niches are generally more forgiving, with higher acceptance of incomplete solutions or failures. In contrast, mature markets have well-defined sets of features that are essential for users to adopt a solution. This means your MVP feature set number will vary significantly based on market maturity, affecting the amount of work required to build a product that can successfully attract users to validate the needs. Moreover, market maturity also determines how tolerant early adopters and the market as a whole will be of errors and bugs in your MVP.