To me, an MVP (Minimum Viable Product) should be small, focused, and built on a clear understanding of user needs. It doesn’t need to be perfect or impressive, but it should be solid enough to respect the user experience first.
I believe MVPs will always have some level of chaos. That’s a part of the process. But without structure, that chaos turns into waste and burnout. We lose time, energy, effort, and most importantly, “belief in the product”.
Over the past few years, I’ve worked on 4 MVPs. Only 1 (Tiki Ads Project) launched as planned with a clear goal. The other 3 faced shifting priorities, unclear users, or spent too much time on details. Some ended up taking over a year to develop, far beyond what an MVP should require. I didn’t lead the projects but being a part of those challenges gave me a front-row view of what works and what doesn’t.
This case study reviews 3 MVP projects where we encountered significant challenges and inefficiencies. It explores what caused us to struggle and waste time + effort, highlights the patterns I observed across these projects, and shares the key lessons I’m carrying forward.
This project was about turning a traditional offline business into a digital platform (Digitization). The team was small, with 12 members. We had UX/UI designers, product managers, developers, QA, and business stakeholders. We had 6 months to launch the MVP. We started from scratch, from learning the offline business, then designing and building the product.
We started by turning every step of the client’s offline process into a digital screen. But we didn’t prioritize which steps mattered most. We treated everything as equally important. That made it hard to focus our time and resources, and in the end, we struggled to deliver the core features that users needed most.
Early on, we spent a lot of time perfecting the UI and adding system validations. These are important, but they came before the core user flows were even complete. This caused delays and made it challenging to deliver the key functionality on schedule.
Treated the MVP like a “mini full product”: We tried to replicate the full offline process instead of focusing on the most valuable parts to test and learn from.
Unclear goals for the MVP: We didn’t clearly decide which features really mattered or what “done” looked like, so it was hard to know if we were on the right track.
Limited time for planning: We jumped into execution too quickly, without taking time to define user flows, set priorities, or set a clear roadmap.
UI-led design approach: We focused on designing screens and UI details early, rather than mapping user flows or aligning design with product goals.
This MVP focused on redesigning and rebuilding existing products from the ground up. The team was mid-sized, with 20 to 30 members. We had product managers, business analysts, UI/UX designers, front-end and back-end developers, and QA. We had a fixed timeline to deliver the MVP features, with speed being the top priority.
We rebuilt the product around 1 major client’s offline workflow. As development went on, we kept adding features and adjusting designs based on their feedback. But we didn’t take time to explore the existing product to see whether other users shared the same needs. As result, we re-created the same features from the existing product without solving the deeper problems they had.
Also, since we focused on delivering fast, we didn’t clarify the purpose, key goals, or user pain points well. This left the team unclear on priorities and unsure how to measure progress or success metrics.
Lack of problem framing: We jumped into solutions without clearly understanding the core problems.
No clear product goals or vision: We didn’t align on what the MVP was supposed to achieve, which made it hard to prioritize features or measure progress.
Too focused on speed: We prioritized speed over planning. This caused us to skip critical steps like defining product goals, understanding user problems, and aligning on what the MVP was really for.
Client-led product direction: We relied heavily on client feedback to guide decisions. This made us reactive, constantly adjusting to requests instead of following a long-term plan, which made it hard for the team to stay aligned
This MVP started from founder’s early idea. The team was small, with 5 members. We had founder, ui/ux designer, and front-end and back-end developers. The project timeline kept getting extended as the product direction shifted repeatedly during development.
At first, we knew who our users were and what we wanted to offer them. But as new ideas came up during development, we kept changing direction without fully evaluating if they were achievable. Later, decisions were driven more by technical limits than by what users actually needed, so some features didn’t work as planned.
We also spent a lot of time perfecting small design details while the main features were still being figured out. We had to redo tasks multiple times, which caused us to lose direction and made it difficult to track progress, stay aligned, and keep everyone motivated.
Shifting product direction: We kept changing the product direction as new ideas came up, which caused instability and delays.
Lack of upfront research: We didn’t spend enough time researching or validating ideas before development. As a result, we couldn’t be sure whether the solutions truly met user needs or were even feasible.
Focus on polish over progress: We spent too much time on design details before the core features were ready. Later, the direction changed, so some of that work had to be redone.
Tech-driven decisions: We made decisions based on technical limits rather than focusing on what users truly needed.
Looking back at all 3 projects, I noticed we ran into some of the same challenges:
We weren’t clear on what the MVP was meant to achieve or which features mattered most.
We didn’t spend enough time understanding user needs. We made assumptions that didn’t always solve the right problems.
We often changed direction and reacted to requests without a steady plan.
We spent too much time polishing the design before core features were even complete.
Without clear direction, it’s hard to keep everyone aligned. That leads to confusion, extra work, and slower progress. I’ve learned that clarity isn’t just a nice-to-have. It’s what helps MVPs stay focused and move forward smoothly.
I’m focusing on building MVPs with clarity and intent. That means starting with well-defined goals and ensuring alignment across the team-s from day one. Speed matters, but only when paired with a solid plan.
Here’s how I’ll approach it moving forward:
Set a primary objective for the MVP. (What are we trying to learn or achieve? validate demand? test usability? or prove technical feasibility?)
Identify the problem to solve and the target user.
Define success metrics or signals.
Focus on solving one clear problem for the target user. (What is the smallest set of features needed to deliver value to the target user?)
Use the MoSCoW method to prioritize features based on impact.
Remove anything that doesn’t directly support learning or validation.
Align team members on:
What’s in-and-out of scope
What success looks like
Who owns what (e.g., product, design, tech, testing)
How product decisions will be made (e.g., PM is final decision-maker)
Define key user flows and create wireframes for the main actions.
Share designs early with internal team-s to get feedback.
Involve target users to test problem-solution fit and usability (only if time allows)
Track progress and ensure the flow from entry → value → success works smoothly.
Say “No” to over-engineering or polishing non-essential parts too early.
Collect feedback from users and internal team-s during MVP use.
Group insights into critical issues, UX challenges, and feature requests.
Prioritize next steps using the RICE method.