Quick definitions. Product Delivery is when we define and fix the scope, timeline and budget before design and engineering begins. An Agile Project is when we assign a team without a pre-specified scope, and that team is set up to swiftly adapt to changes.
So what makes Agile better for live products than the clearly-defined Product Delivery?
Fixing the scope and timeline may seem super simple from afar. Features are specified before engineering starts so everyone knows what to work on, estimates are made, sprints are planned — so just follow them and the product will be ready to be shipped in no time. Easy, right?
Not quite. Especially with a live product, reality often proves to be more complex. And Agile is made for complexity.
Two Key Reasons Why Live Products Benefit From Agile
1. The market and technologies keep changing, fast.
Software development is a fast-paced industry where changes come in daily. After shipping the MVP, you cannot just expect it to work forever — you need to innovate constantly.
On top of that, initial estimates are based on available information, and they get more precise once the engineering starts and we have more data to work with.
Maybe the third-party integration we were planning to do is slightly more complex. Maybe we need to refactor some old code to make new things work. Or maybe one of our providers released an update that broke a few things in the middle of the project.
You have to be well-equipped to adapt to these factors as you go.
2. You need to be able to iterate based on user feedback.
When building and shaping the MVP, no matter your dedication, all you’re working with are assumptions.
If you do your homework right and have a firm grasp on your industry, chances are that these assumptions are as accurate as they can get. But once you launch, you very often realize that your users are not using the product exactly how you’d imagined.
It’s vital to collect data as soon as possible, analyze your users’ behavior and make prompt changes based on your learnings.
There’s Always Additional Work on Top of New Features
Once an app is live, the road ahead is packed with to-dos: analyzing bugs, helping your users, changing priorities based on the feedback you get and much more.
These tasks may seem small individually, but there are usually many of them, especially in the first weeks after launch. This can cause delays — or, better said, scope reprioritization.
Agile methodologies expect all of these things to happen and propose tools to handle them effectively. On the other side, if you’re working with and committed to a fixed scope, accommodating each new minor request can quickly become quite time-consuming. Agile practices help streamline this process, making it more effective and adaptable.
We often work with startups who just recently released the MVP of their app. In this stage of the product lifecycle, changes are natural. Agile is all about trying to prevent unnecessary changes while having an effective flow in place to process the changes that make sense.
A fixed scope doesn’t allow you to make either of these moves nearly as smoothly. Even though it may seem easier to just stick to a pre-defined scope, the ultimate goal is to build good products. And to build good products, you need to embrace change.
Precisely Planned Changes > Reactive Chaos
A good Product Manager will have a change request process in place. We determine whether it makes sense to prioritize a change or not — that’s a crucial part of our job. We guide you through the hoards of incoming ideas and user feedback, help the team focus on the ones with the greatest added value and steer the product in the right direction.
How do we make sure there aren’t too many changes?
Agile definitely shouldn’t cause chaos. Even when you’re able to adapt to incoming change requests quickly, there should always be a long-term vision and a roadmap for the product, usually set and refined quarterly. The vision and the roadmap let the whole team know what they’re working toward — and Agile lets you make the changes necessary to ensure you can achieve these goals or adjust them slightly as you discover new things.
After building the roadmap for the upcoming few months, the roadmap is split into individual tasks, which are then grouped into sprints. A sprint usually lasts two weeks — or one week for smaller, fast-paced projects. We always commit to the work planned one sprint ahead; the rest of the sprints are planned loosely based on the long-term vision, and we can adapt to the ever-changing conditions.
In each sprint, we leave space for bug fixing, refactoring, troubleshooting, writing tests, improving accessibility and keeping our tech stack up to date. For live products, that usually takes 15–20% of engineering time. It helps ensure the product will stay in good shape and will be scalable as you continue shipping new features.
So When Is Product Delivery the Right Call?
While Agile is our go-to for live products, there are a lot of times when we pick the Product Delivery approach. A few examples:
When shipping an MVP, we want to get the product to the market as soon as possible. In these cases, we usually define the scope prior to starting the engineering, trying to get something to the market quickly to start collecting feedback rather than striving for an ideal product without any user input.
For existing products, sometimes we’re just adding a smaller feature; if it’s a one-off update and we can define it well, fixing the scope makes it quick and easy.
For Scaling and Growth, Agile Is the Way to Go
Not fixing the scope and timeline does not mean the team works at a slower pace. Nor does it mean they won’t finish all the features. At STRV, we always deliver as soon as possible, regardless of whether there is a hard deadline or not. We care about the product and want it to succeed — and for that to happen, pivoting in the middle of MVP development is sometimes a must. That’s why we embrace the changes and are ready to go Agile when needed.
