Building compelling and valuable technology products requires optimization of means, right tooling and methods. Understanding of the limitations and managing constraints are also key success factors throughout the delivery processes.
A common practice, software development teams tend to often use methodologies such as Cycle V, Scrum, Kanban etc…. and then build up. Some fall under the Agile framework and others just do not 😜. Agile is good and by construction iterative, but it is a high-level framework that primarily allows stakeholders to communicate iteratively and sync their roadmaps.
Do not get us wrong, this Blog is not about Agile, and definitely not the traditional use of it.
This is a blog post about how to make efficient and timely decisions using tools and skills collected over many years of building software products. How to navigate simple and complicated questions when trying to push a product to Production with blazing speed. It is about exploring, testing, and quickly learn while building things that perhaps might be reused to get to Product Market Fit or some kind of value for the user or customer.
Our experience shows that the Test & Review process works very well when exploring and navigating uncharted waters. It works extremely well in the case of early-stage start-ups, digital factories or teams that are mandated to push a new product outside of the product line of the company they work at.
This being said, the iterative development might work, but we would not recommend it to be used when the teams already have an established product roadmap about a solution that has most of its parts known to the builders.
With all of this in mind, we should know that iterating has many faces and can use many tools. A skilled iterator will be able to employ and combine these tools based on different variables at hand:
How urgent is the feature to iterate on?
How much data do we know about that feature?
Is it a leap of faith of just a small upgrade vis a vis existing software?
What is the path of least resistance to have it done and in production in front of users to get some validation? The path of least resistance is not always software.
As a matter of fact, the best software is no software. If we do not have to build, then we should not.
The iterative process combines skills of risk tolerance, technology expertise, information about existing solutions, gut feeling, and the ability to use incomplete pieces of software and show them as complete. It implies as well the ability to reduce the requirement to the bare minimum that will provide value to the user, and sometimes fight with others to only include that bare minimum, finance, cost management, and leadership.
At the end of the day, we should always keep in mind that we are iterating. This means that we are in test mode. We are scientists in the lab trying to find a cure to pains. We have tight budgets (early-stage companies), or we have to be disciplined to not throw money out of the window (big companies that are exploring. Either ways we should stay nimble, move quickly, take small steps and go after the goals that are going to yield the highest ROI.
Based on our experience, the following are the main takeaways:
The iterative process allows us to build the roadmap to develop.
In most cases of early-stage companies, iterating is the only tool to achieve product-market fit, the wholly grail achievement of any start-up. “Startups almost never get it right the first time. Much more commonly you launch something, and no one cares. Don't assume when this happens that you've failed. That's normal for startups. But don't sit around doing nothing. Iterate." Paul Graham.
Most people think code is the only tool to explore i.e. the longer go-to-market strategy.
Fewer software developments, Maximum speed, collect highest possible ROI
Developers are unable to do that in most cases because they will get lost
What are the inputs to push to the dev team i.e. nice to have vs must-have?