Lean Product Development: How to Build Products That People Actually Use

96% of businesses never make it past the first plateau

There's a growth curve that shows up in almost every startup and product strategy deck. Most businesses cluster around the same revenue plateau, and when they try to jump to the next one, they hit what people like to call the Valley of Death.

I prefer to call it the Valley of Innovation. You're burning resources, capital, time, and focus to get to that next stage. That's not death. That's the most innovative period your business will go through. The question is whether you survive it.

We work with product teams across B2B organizations, from early stage products to mature platforms shipping new features. The context varies. Sometimes it's a company building their first client facing digital product. Sometimes it's a team with an existing platform that's grown unwieldy and needs to ship a new capability without adding more technical debt. The lean product development principles we keep coming back to are the same regardless of company size or product maturity. There are more than four, but these four come up in every engagement, and they show up across our broader digital strategy, UX, and product design resources.

Principle 1: Validate early

The first reality check: 42% of failed startups cite no market need as the reason they failed. They didn't test anything. They didn't talk to users. They didn't talk to prospects. They just built.

The antidote to this is the MVP (Minimum Viable Product). We've written about what MVPs actually are and why they matter for customer experience in depth before, so I won't rehash the full philosophy here. The short version: an MVP exists to test willingness to pay, attract early champions, surface UX friction, and de-risk your technical assumptions. If you solve this problem, will people pay for it? Will they use it? That's the whole question.

The problem we see constantly is that teams say "MVP" but deploy something that's clearly a beta or a first product launch. They put real marketing dollars behind it. They staff up around it. That's not minimum viable. An MVP should be cardboard, paper, popsicle stick level scrappy. Dropbox validated with a three minute explainer video and no product at all. Their wait list went from 5,000 to 75,000. Airbnb was an air mattress in an apartment during a conference. Groupon ran on WordPress, manually creating PDFs and emailing them to users.

An MVP is something you deliver in 24 to 72 hours. If it took longer than that, it probably wasn't one. Even tools like Lovable that speed up the development process should produce something scrappy, not something that looks finished. Do not waste time perfecting something that no one needs.

Principle 2: Prototype to learn

Your MVP was a success. You've validated the need. Now you prototype. This is where I spend the most of my time with teams.

Write your product requirements first. Even a short list gives your product designer something to follow. We see a lot of teams skip this step entirely and jump into prototyping without any shared understanding of what they're building. The reasoning is usually speed, they want to "just start designing." But prototyping without requirements is how you end up with something that looks great and solves the wrong problem. The requirements document doesn't need to be long. A page is fine. It just needs to exist so everyone on the product team is working from the same brief.

The bigger issue is that most teams treat prototyping as linear. Brief goes in, prototype comes out, everyone reviews it once, and it moves to development. That's the 10,000 foot view. The reality is prototyping should be a tight iterative loop: prototype, test, analyze, define, then back to prototyping. Stay in that cycle until you've weeded out as much ambiguity as possible.

The business case for this is straightforward. 80% of features in an average product are rarely ever used. Teams who prototype well routinely report less rework and faster time to market. McKinsey's 'Business Value of Design' research found up to 30% reduction in development costs and 50% faster time to market for companies that invest in design and prototyping early. And the math on design changes versus development changes is stark. A designer moving an element 100 pixels to the right or relocating it to a different screen takes minutes. Getting a developer to open their IDE, recode, reposition, deploy, and test the same change is dramatically more expensive. AI is closing that gap, but the ratio still holds.

You don't need to start from scratch. Component libraries like ShadCN, Ant Design, and Material UI get your design team moving quickly with reusable, drag and drop components. Most of these libraries also have companion code systems, so your developers get the same head start. But the real value of prototyping is user testing. Tools like Maze let you put a prototype in front of real users and collect both quantitative and qualitative data on how they interact with your product design. What users tell you and what they actually do are two very different things. You need both signals, especially as design and development processes converge with AI-driven tools.

Sketch first, polish later. Stay rough as long as possible because low fidelity prototypes are easy to change. As you move to higher fidelity, applying brand, building out a design system, the cost of change goes up. Even design debt accumulates. Stay in the sketch phase until you're confident enough to commit.

Principle 3: Build lean

60 to 70% of a product's lifetime cost goes to maintenance. That number should reframe how you think about your product budget. If you scale too early and build too much infrastructure before you've validated what your users actually need, you end up maintaining features nobody uses. That's where most product budgets go to die.

We see this pattern with a lot of B2B product teams. They build for 10,000 users when they have 10. The technology to support scale can come later. What matters early is that the core experience works for your first cohort.

Remember the Groupon example. Behind the curtain it was chaos, manual PDF creation, swivel chair operations, people emailing things by hand. Their users never knew. They latched on to the service and the value. The behind the scenes chaos is perfectly normal at this stage and it's temporary.

The principle here is assemble, don't invent. There's an enormous ecosystem of low code, no code, and API tools that let you stitch together a working product before you write custom code. Authentication, payments, notifications, scheduling, file storage. Someone has already built reliable, scalable versions of all of these. Use them. Custom build the parts that create your unique value. Wizard of Oz the rest.

This is where lean product development and lean product design overlap. The product design decisions you make at this stage determine your maintenance costs for years. Every custom built component is a component your team has to maintain, document, and debug. The question to ask for each piece of functionality: is this the thing that makes our product different? If the answer is no, find a service or library that handles it and move on. Focus your engineering time on the pieces that only you can build.

Principle 4: Scale intentionally

12% of features drive 80% of daily usage. That stat alone should make every product manager pause before greenlighting the next feature request.

Once you have a product in the market with real users, the temptation is to build everything everyone asks for. That's how products bloat, slow down, and lose the clarity that made them useful in the first place. You need systems to resist that pull.

Instrument everything. Install the tools to collect feedback and behavioral data. Combine qualitative insights (what people say they want) with quantitative signals (what they actually do). These two data sets will regularly contradict each other. Users will tell you they want a dashboard with more customization options, then analytics will show that 90% of them never change the default view. That contradiction is where the real product insights live.

Score the opportunities. We use RICE, a prioritization framework that evaluates Reach, Impact, Confidence, and Effort. It produces a numerical score, which is useful because it removes emotion from the decision. It's a signal, not a mandate, but it's a much better starting point than whoever argued loudest in the last meeting.

Then ship lean experiments. One of the most effective tactics is the painted door. Put a button in your navigation or on your landing page. "Sign up for the beta." "Join the waitlist." You're testing whether users are interested in a feature before you build it. You collect demand signals with zero development investment. If the interest is there, build it. If the button gets ignored, you've saved yourself weeks of work and the ongoing maintenance burden that comes with every shipped feature.

Data is the antidote to gut feel. And sometimes the smartest product decision is deletion.

A note on AI prototyping tools

During a recent talk, someone asked a question that keeps coming up in product conversations. They'd been using AI tools like Lovable to build prototypes, and the prototypes looked finished. Polished. Real. Their stakeholders and early users started treating them like the actual product. "It looks done, let's ship it."

The problem is that what they had was a proof of concept. It looked like a product, but it didn't have the backend or the infrastructure to operate at any real volume. This is a new communication challenge that AI tools have introduced. When your prototype looks production ready, you need to be explicit with your audience about what stage you're actually at.

Frame it as a proof of concept. Tell your stakeholders: we have something to play with, we've validated the need, and now we need to build the real infrastructure to scale.

The language matters. "This is proof that we should invest" lands differently than "this is almost done." One leads to smart product development. The other leads to premature scaling.