Over investing in unnecessary work is one of my phobias, especially when it comes to software development.
My stance on effective early stage product development is to roadmap the idea based on assumptions, experience and available data, and then ship fast, incremental features that move towards the relevant business goal.
Incremental is the key word here.
With this approach, we identify the "key" metrics within each incremental step we take, and then we simply measure them as soon as possible, and continuously.
This keeps things simple from a planning perspective. It also chokes out the often deadly "over building disease" before it ever has a chance to spread and infect the company culture.
Done right, fast feedback cycles help to reduce wasted effort in early product ideation, encourages experimentation before committing heavy resources and builds confidence in decisions by grounding them in real signals.
The final outcome is simple: Less money invested in bad products, and the high potential products get the attention they deserve.
Identifying Feedback Loops Early
Identifying the feedback loops that need to be measured early into the product development lifecycle means we protect ourselves, and our companies, from over-building or over-engineering.
It means we test assumptions fast, fail or succeed fast and ultimately understand exactly what's already working, what needs tweaked and when to move onto the next step.
So, how do we identify feedback loops early?
First, after being sent requirements for the project, write out a list of the steps your user has to go through for the product to be a success.
Next, identify the metric to measure success for each step.
Finally, identify the "show stopping" steps that must be successful to "unlock" the next step.
A simple example is a sign up flow and an on-boarding flow. If the sign up flow is not successfully converting yet, then optimizing the on-boarding flow is probably premature.
If the sign up flow never works, then there's probably an underlying issue that needs addressed. (Are there technical bugs? Bad market-fit? Is the traffic the right quality? Confusing user experience? etc)
That underlying issue might be a death sentence to the business or product, if it isn't openly discussed in a unemotional and data driven way.
In this case a company can simply ask: "Why are users not signing up for the product?" and pull in the relevant stakeholders to triage the situation.
Metrics that Guide Product Creation
Establishing the main metric that defines success for each step is critical.
Without this, it is easy to become adrift like a rudderless boat, or burn valuable time monitoring meaningless metrics.
The main metrics are typically very simple, but will depend on the product.
An unproven product launching a MVP may simply track user sign ups, and revenue to start.
The outcome of what those numbers look like will greatly influence where attention should flow next.
For example, if users are signing up rapidly and revenue is already starting to come in, then shifting towards user success, revenue expansion and network effects might be the next best area of focus. However, if users are not signing up at a favourable rate, then investigating why that might be the case becomes more important than "downstream" areas of opportunity.
If you need to dig into any certain area, the company can then begin to look at things like engagement, retention, conversion and time-to-value data points at relevant chokepoints.
Being able to visibly see the "why" behind a product not working frees up an engineers time to move onto the next thing, without being driven by potentially low impact work.
From an engineering perspective, it might be better to pull from the backlog and prioritize something different while the relevant stakeholders "figure out" the business problem that exists. This is actually a big bonus, because there's always tech debt or refactors that need an engineers attention that ultimately help the company move faster anyways.
Key Takeaways
- Start small: Define and test assumptions early.
- Track what matters: Metrics guide product direction even before revenue.
- Align teams: Marketing, product, and engineering should share the same signals.
- Stay scrappy: Smaller teams can use fast feedback cycles as a competitive advantage.
- Think iterative: Progress is about learning quickly, not just building quickly.