The meeting between iterative product development and a company used to approaching product development through the project-lens can be quite harsh.
On one hand, you have set budgets and revenue targets. The project deliveries have been planned out in detail for the coming months, quarters or even years, with a chain of dependencies for the rest of the year.
On the other hand, you need to follow up deliveries and make day-to-day decisions that affect the scope and the end product drastically in a true agile manner.
All the while nobody can give an answer to whether you’ll hit your targets or not. And you, as a stakeholder or project owner, just want to know when it will be done!
Here’s the deal…
There are a few things to note when moving into this world of digitalising organisations and iterative product development.
- Agile™️ doesn’t mean faster or cheaper.
- You decide when it’s done.
- Product development is hard.
If you’re willing to take my word for it then you can stop reading now. Otherwise, please continue…
Agile / DevOps / Lean doesn’t mean faster, cheaper or easier
Digitisation has been sold into organisations as the “way to go” and alongside this the notion of some form of agile software development. The implication (or outright promise) is that this form of development will be faster, cheaper or both. There are no guarantees of this.
Instead, what these practices mean is that you are able to test your assumptions in a more iterative manner. This means you can create just enough of a product that will allow a customer to use it and give you feedback before your next iteration. So, in this sense, it’s a lot cheaper to verify you are on the right path, and the cost of course-correcting is a lower than if this was a project going over several months or years.
Working this way is more demanding of your time, as you are now part of the team that builds and discovers the product — you need to be available on a more ad-hoc schedule. There are more small follow-up meetings and constant changes to priorities based on customer feedback, or new opportunities. Working like this is engaging and fun, but it can also be draining. Especially if you’re used to the more traditional “ordering” of software through larger “waterfall” -projects.
Product Development is Hard
The hardest part of building a software product is knowing what to build. You may have an idea of what you want to create, but will that actually meet people’s needs? Saying you need an app or a service doesn’t instantly make it something that people want to use. The only way to find the market-fit is to test it out with real customers and users. This is what an iterative development methodology offers — the chance to test assumptions before you run out of budget (money, time, goodwill, etc).
Gone are the days where business and in-house customers accepted sub-par products to be able to get their work done. Consumers are used to sleek, intuitive apps on the web and their devices. There’s no magic switch that causes these same people to lower the bar of what they expect when they enter their work setting.
This expectation of quality becomes a challenge for businesses wanting to raise the bar. As the quality of the products improves, so does the need to build the right thing. It is crucial to verify whether the pain you are trying to address is one the people using your product actually feel, and want dealt with.
To keep up with this pace means focusing more on product development as a core discipline, instead of something to be outsourced or managed from afar.
You decide when it’s done.
The dirty secret is that “it” is never really done — the elusive product remains a moving target. Getting something out the door is just the first step. Instead, the focus should be:
- When is the product good enough to be valuable to the people using it?
- How much are you willing to spend to find out how close you are to fulfilling those needs?
- How do you know the product is actually attending to the needs and delivering value?
With an iterative process, you have the opportunity to approach answering these questions and respond by changing the direction of your product. But the only way I’ve found to get real feedback is to give full slices of functionality in front of real users.
Sketches, prototypes, proofs of concepts and minimum viable products are all viable approaches to elicit feedback — the earlier the better. Pick your flavour, be harsh with the scope, and get a working product out there!
Finally
Organisations’ need for fixed budgets, scopes and roadmaps can hinder you from realising the tantalising promise of value in a truly iterative product development cycle. That value is the agility to be able to respond to changing needs, and new opportunities.
Embrace experimentation through continuous feedback cycles and adjust the reality of where you are with a product based on them. Based on these feedback cycles you’ll know when you’re done.
Clap ? or follow Dolittle to read more about how we believe in enabling others to create products that help users feel like superheroes.
Cover Photo byJosé Alejandro Cuffia on Unsplash
This post appeared originally on the Dolittle blog
