Product & Agile
Why do we love product management and agile ways of working? Because we like getting things done for and with our clients.
If your team is cranking out technology solutions that provide true business value – no matter which approach you use – awesome! We’re not here arguing for change for change’s sake. But if you see some daylight between what business stakeholders are asking for and what technology teams are able to deliver, may we offer up some ideas that could help?
First, a quick primer on product management and agile practices.
Product management is a strategic approach that focuses on delivering value to customers through iterative development, continuous feedback, and cross-functional collaboration. Unlike traditional waterfall project management, which follows a linear and sequential process, product management and agile practices embrace adaptability and incremental progress.
Agile methodologies, such as Scrum or Kanban, break work into smaller cycles called sprints, enabling teams to respond quickly to changes and deliver working solutions more frequently. (We often work with Scaled Agile practices, where multiple product teams work in parallel to deliver even more for customers!)
In contrast, waterfall project management relies on upfront planning and fixed phases like requirements, design, implementation, testing, and go-live. This makes it harder to adjust course once the project is underway.
Product management and agile approaches encourage ongoing stakeholder engagement and regular reassessment of priorities, ensuring that teams are always aligned with customer needs and business goals.
Now that you’re familiar with the what of product and agile, let’s talk more about the why.
Using product management in an agile manner allows us to collaborate with customers far more effectively than we can using waterfall project management. This is based on several factors:
Our first idea for how to solve a problem is often not our best… so getting through that first idea to the better one after it, quickly enough to do something about it, helps us develop a better solution overall.
There’s a comfort in the 120-page requirements document: it seems so thorough, like we’ve thought of everything. But the moment we start developing against the requirements, we have questions:
“Did they actually mean x or y?”
“I can develop this as stated, but wouldn’t it be better to anticipate the next need, too?”
When we embrace agile mindsets and methods, we do really good thinking about what we need (often with our customers), we make it happen, and we evaluate what’s working well and what isn’t. Improvement is baked into the process, and we often deliberately create a minimum viable product or a proof of concept first, to get the lessons learned flowing as quickly as possible.
Shorter, iterative development lets us fail faster.
The product model clarifies ownership and pushes decision-making closer to the customer.
In waterfall project management, we typically have business analysts compiling requirements from customers, then an architect designing a solution, developers getting hands on keyboards, you get the picture. Lots of people making lots of handoffs to get the solution developed.
In a product model, we still have many of those roles, but they’re working together much of the time, with many fewer handoffs. Discovery includes customers, the product owner, business analysts, the solution architect, and developers – so everyone is hearing customer requests together. Developers can ask questions directly of customers, rather than waiting several weeks (months?!) later to read a requirements document and discuss with the BA.
You may have noticed a new role in the product list: product owner. In product management, we typically specify a product owner for a specific piece of valuable functionality. This isn’t the solution owner you may be familiar with – ERP owner, CRM owner, etc. Rather, it’s the “procure-to-pay product owner” or the “digital marketing tools owner.”
By specifying a product owner and giving them the runway to create a solution to delivers a specific set of value to their customers, we unlock better prioritization and decision-making.
In case we haven’t convinced you that product management and agile development set teams up to deliver success, let’s tackle one final topic.
Waterfall delivery can set up defensiveness between stakeholder groups. Drawing on (embarrassing!) personal experience, we can remember a data project many years back with complicated business needs and lots of data sources.
One User Acceptance Testing cycle of some metrics in a report got tense when the business stakeholders said, “why is x this way?” We looked back at the requirements and, sure enough, that’s what they had signed off on. (We probably even told them this – yikes!)
They said, “well that doesn’t help us. We actually need y.” (Note that this was just one of several components in the deployment, so holding it back from release would prevent other valuable items from being released, too.)
Thankfully cooler heads prevailed that we could update the metric calculation and report in the next release (quite a few weeks later), and we pushed x to prod knowing that it would be replaced by y later.
Painful trip down memory lane complete.
What if, instead of the defensiveness and at-times animosity of waterfall deployment, we could do true discovery and prototyping with customers? And, if we knew that we’d keep updating the product next week, wouldn’t it take the temperature down on any one update? Thankfully, yes.
Discovery is much more effective in an iterative, collaborative environment. We get more comfortable with terminology and business needs, and all groups involved can suggest ways of solving the stated business problems. Then, when we have something to review, customers were involved in discovery just days or weeks prior, so the concepts still resonate.
Discovery is much richer in an iterative, deliberately collaborative environment.
If you’re realizing you want to benefit from product management and agile methods, we’ve been there! The FlexPoint team can come alongside you in adopting product management or agile practices – or both.
If you’re looking for an immediate next step, we recommend picking one of these ideas and trying it out:
Run retrospectives to reflect on what’s working and where improvements can be made.
Promote cross-functional teamwork, bringing together product, engineering, design, and business experts to collaborate on the next solution you develop.
POC one portion of your technology solution as a product: define clear objectives and outcomes for the area, focusing on problems your customers want to solve.
Adopt short, iterative development cycles and hold regular reviews to gather feedback and adjust priorities as needed.
Embrace transparency by maintaining visible backlogs and progress boards, and encourage open communication within your team.
Interested in learning more?
