Many organizations approach development with a project mindset: define a scope, complete the work, and move on. It sounds efficient, but it causes a lot of painful side effects. Teams often find themselves juggling conflicting priorities from different stakeholders. Technical debt mounts as they succumb to pressure to split their focus. Patching and maintaining features created in past projects slows new projects. Leaders wonder why agile transformations haven’t delivered better results. The reason is that agility isn’t about managing projects with set scopes and timelines; it’s about delivering continuous value through products that evolve based on customer needs. Adopting a product mindset changes the game.
A New Approach: Product Thinking
In a product model, teams are given problems to solve instead of projects to complete. They become invested in delivering solutions that benefit customers and the business. It is a long-term, sustainable approach that minimizes technical debt. Teams weigh decisions about new features and support work against the overall product value. They adapt to customer needs continuously, creating better outcomes for everyone.
Illustrating the Shift
The following story illustrates how adopting a product mindset transformed a stalled initiative into a valuable product. (I have changed some details to maintain client confidentiality.)
Background
My client was the IT department for a sporting goods manufacturer. When the company was founded, they relied on a rudimentary database to make product pricing decisions. In the earliest days, it worked well enough. But as the company and its product lines grew, so did the complexity of the database. It wasn’t designed to handle the increased volume of data or the more sophisticated pricing calculations now required. Performance had degraded significantly, with some queries taking several minutes to run. Worse still, no documentation existed. No one knew how to upgrade it or adapt it. It was a brittle, opaque system that constrained pricing decisions and slowed the company’s ability to adapt to market needs.
Challenge: No Vision
A new project sprang up: replace the pricing tool! The problem was that no one could agree on what exactly that should look like. Build a new database? Hire experts to fix the old one? Update the front end? Build a web app? A mobile app? Worse still—no one would agree on what features were important and what weren’t. Should they focus first on replicating what they already had? Or should they focus on building features that didn’t exist in the current tool?
After nine months, they still could not agree on requirements and they were no closer to solving anyone’s problems. The company was talking about laying off the entire group and scrapping the project. They asked for my help in salvaging their initiative—and their jobs. I suggested that instead of viewing it as a project to complete, they approach it as a product to be developed.
Creating a Product Vision
First, I had them take a step back from trying to identify requirements. A detailed list of features wouldn’t give them the flexibility to adapt to changes. They needed a guideline that would help them make sound decisions as new needs arose. They needed a product vision.
I asked them to define who they saw as their users and what specific challenges these users faced. For instance, pricing managers were spending hours manually comparing prices due to the slow, outdated system. How could they provide value that would directly address these challenges? Next, I asked them to define the business benefits—such as reducing decision-making time and improving pricing accuracy—that the company would realize. Once they agreed on these aspects, I had them craft a vision statement:
We will develop a tool for pricing managers that will facilitate their decision-making by providing fast, real-time price comparison data. As a result, we will optimize our sales and profitability metrics.
This vision includes a “what”: a tool for pricing managers. But more importantly, it provides an answer to why they were building this tool. Future decisions could be guided by the purpose of providing fast, real-time data. The vision also provided the rubric to use as they planned. In order to make the cut, new features had to align with the goal of optimizing sales and profitability.
Defining a Product Goal
Now that they had a north star to guide them, they needed to decide the first leg of the journey: the Product Goal. This Product Goal gave the team a concrete, achievable target, which was crucial compared to the vague, all-encompassing plans they had struggled with before.
Collaborative Planning with Product Goal
The Product Owner decided to focus on supporting pricing managers for a new line of ski wear. The current tool had nothing to offer them. They’d been doing little more than guesswork about prices for their line. The team’s first Product Goal was:
Deliver a web app that allows SkiFast pricing managers to forecast sales based on changing prices for their latest product line.
The Product Owner held a workshop where the team collaborated with key stakeholders on the initial Product Backlog. The first items identified focused on what users wanted to do. After that, the team built out more Product Backlog Items around infrastructure work needed to bring those features to life. The workshop took fewer than three days. Compare that to the nine months they’d spent before with no progress!
From Paralysis to Product
As its first Sprint goal, the team decided to deliver the ability to perform basic price comparisons between two similar products. When they showed the feature at Sprint Review, the buzz was incredible. “I’ve had to go on nothing but guesswork until now. This is a game-changer,” one stakeholder said. The rest of the Sprint Review was filled with excited discussion about what could be done next.
The team was thrilled, too. In less than a month, they’d gone from making no progress—and fearing for their jobs— to delivering a valuable product. After building a powerful set of tools for the SkiFast pricing managers, they moved on to another product lines. In time, they did more than replace the old tool, but built a superior one that could grow with the business.
If your team is struggling with unclear priorities and mounting technical debt, it’s time to ditch the project mindset and embrace a product-focused approach with Scrum to unlock your team’s potential and deliver continuous value.
Fuente: https://ift.tt/HJkLRUD
Publicado: October 24, 2024 at 07:36AM
