Make it work, make it good, make it scale (fast)!
This essay has an accompanying web application that shows each stage. https://five-stages-product-development.pages.dev/
Why product development is confusing
Building product is a confusing process. There are engineering and design best practices to consider which oftentimes conflict with iteration speed.
For instance: Stability by testing versus iteration speed. Test-Driven Development (TDD) argues that tests should be written first. This is perfect when you’re coding for stability. However, iteration is inherently unstable. By having tests early on, every iteration forces code changes in 2 places: business logic and tests.
Some technical founders saw this tradeoff and spoke about delaying writing tests in this forum: Startup Technology — Advice for Technical Founders (22:40).
Take this other tradeoff: Great UI/UX versus iteration speed. For frontend engineering, great UI/UX often causes code overhead. The team is forced to work towards 2 concurrent goals: make it work and make it easy to use. This overhead is a bottleneck to finding product-market fit. Great UI/UX is important, but iteration speed is more so. Great UI/UX makes your product perfect, but perfection is the enemy of done.
We prefer passable UI/UX over an unreleased product.
Disclaimer
This is how we build product in Dashlabs.ai. There are other methods, but this one works best for us so far. We started this idea as an internal document to help the team understand building product complexity.
We published this essay to get feedback from others so that we will be aware of our own shortcomings.
Our goal is to find product-market fit and get product to be self-serve as fast as possible. We introduced our 5 stages here with a short description of each. In the coming weeks, we’ll publish stage-specific posts that dive into details. We’ll include code examples, team-specific responsibilities, and our own insights.
1. Find a real use-case
A mistake product people often make is thinking they know what users want. They conceptualize, wireframe, and build products without a user. This is considerable effort invested without assurance of returns—a risky investment. Talking to users is an easy way to de-risk that investment. A real user gives you a use-case and a feedback loop to improve. Both business and engineering should work in getting a real user.
In this clip, Jeff Bezos explains why reducing risk is important for startups.
[Stage specific post coming soon]
2. Build a single use-case feature
Once you’ve found that user, build everything they need. Your goal is to prove a problem-solution fit. Iterate until your user is thoroughly satisfied and starts paying for it.
On onboarding users: Engineers should handhold the user into using this feature since there is little to no frontend tools for the business team to use.
[Stage specific post coming soon]
3. Discover use-case variants
A paying user means you’ve solved someone’s problem. The next step is to solve similar problems. You’ll likely learn that other people have slightly varying use-cases.
Your goal is to learn the many ways people use this feature. Focus on onboarding as many users as you can. Managing variations will be hard… so instead of trying to abstract and optimize code, accrue technical debt and hardcode the customizations in your codebase as needed. You are successful when you’re confident you’ve found most use-case variants.
On testing code: At this point, specific sections of the codebase will be used exclusively by individual users. If that section fails, only that user is affected. Unless this feature is life or death for your user, there is no real benefit to writing tests here. If your feature has issues, your user will tell you. Premature abstraction here is a poor use of engineering time. Allocate all resources to discovering use-case variants.
On onboarding users: Still little to no frontend tools by now. Engineering should handle onboarding.
[Stage specific post coming soon]
4. Abstract custom logic
This is when hardcoding stops! Business should manage client expectations to give engineering space to refactor and pay down technical debt.
Customization moves away from the codebase and into the database. This stage ends when new customization is accommodated without new code.
At this stage, the chances of product failure is high. Engineering will struggle not to cause bugs. Business will struggle when engineering fails. That is why it is important for a clear bug handling system to be in place.
Some users might complain—ask why this stage is necessary. The answer, simply put, is that without this stage, product will slowly break. The codebase just cannot infinitely grow with hardcoded logic.
On testing code: Code failure is expensive because more users rely on the same piece of code. Backend tests should be written.
On onboarding users: Alongside a customizable backend is a frontend that controls it. Build a simple frontend to handover the business team. New users should be onboarded by the business team—not engineers.
[Stage specific post coming soon]
5. Improve user experience to self-serve
At this stage, you have a customizable backend that can accommodate different use-case variants. This, along with an accompanying frontend, is enough to solve most problems in the market. But if users can’t self-serve, this feature won’t scale.
Get a UX designer to solve this last stretch. Since most of the core backend is built, engineers are more confident in iterating frontend code.
This stage ends when the majority of your users are able to use the product without external help. This is the holy grail of feature development. This is where you want to be!
[Stage specific post coming soon]
The ideas here are a product of the Dashlabs.ai team.
Bryan Giger and I will share a detailed version of this idea in a talk sometime in the future. Our goal is to share our experience of building software amid business constraints. The detailed version will have code examples from Dashlabs.ai. as well as anecdotes surrounding it. This essay is our thoughts v0 — launched for feedback.
