From projects to products: 5 ways leaders can think differently about delivering value
Changing the way companies bring ideas to market is about re-focusing the IT department around product delivery, rather than project management. The move from projects to products improves the speed of product delivery, allows companies to be more innovative, and ensures that the product being developed is one that customers actually desire and would buy.
This transformation needs to be guided by company leadership, who need to understand the difference between project management and product delivery (the chart below describes a few of the most important attributes), and then nurture product managers and owners who can execute change within the company.
Exploring those key attributes reveals five shifts that organizations need to work on in order to embrace product management.
1. Organizing around ideas, not functions/departments
The ultimate goal of any organization should be to flow the most valuable ideas into the hands of customers in a way that guarantees a great experience. To do that, leaders need to maximize their resources: the people who develop and deliver these ideas.
Lots of different models have been designed to help leaders organize their departments and teams productively, but many lead to station-to-station work with too many handoffs and friction, which slows down productivity end-to-end, and actually damages the throughput of value. Instead, leaders should align work to individuals based on the most important ideas, products and service, and not on functional hierarchies.
In the past, we’ve described an Idea Management Model that asks a series of questions designed to help you arrive at a solution for any problem:
- Why do we want/need to do something?
- How might we go about doing it?
- What are we actually going to do?
- When will we be able to say it worked (or didn’t)?
When you evaluate product ideas with these questions in mind, you can create organizational structures that are focused on the delivery of value as they work toward bringing the idea to fruition.
2. Governing for experimentation, not certainty
As we wrote in a prior blog in this series, the principles of traditional project management assume certainty. In other words, plans are created and work progresses under the assumption that the same factors that existed at the idea’s inception will continue to exist when it is delivered.
Of course, nothing is ever certain. Tom Wujec’s TED Talk about the Marshmallow Game demonstrated that when teams assume certainty, they inhibit the chance for experimentation. Teams that built freestanding towers out of marshmallows picked up on the patterns and qualities of the most successful towers from previous runs of the game, so when they were asked to start over and create a new tower, they simply followed the path that they assumed led to the best results last time. This offered no opportunity for experimentation and failed to enable improvement in tower design or learning from new experiences.
Instead, leaders should prioritize continual evaluation and validation. Feedback loops need to be in place so that teams always have insight into what’s working and what’s not when it comes to product workflow, strategy and vision. Product teams shouldn’t lean on assumptions or what feels familiar – they should always be evaluating what they know and don’t know about a new situation, so that they can improve.
3. Competing for value propositions, not budgets
Value propositions can guide not only how you organize a team, but also how you prioritize product work over time. Companies should spend as much time throughout the organization discussing and debating where value exists and how they might maximize it throughout the development process as they do discussing budgets and creating estimates. This would create an environment where more focus would be placed on the customer and less time would be used up debating estimates that typically turn out to be wrong in any case.
How do you decide which ideas to work on first? Which features should be delivered first, and which can wait a while longer? Effective leaders answer these questions by understanding the benefits that the intended product or service should bring to customers and the organization, and prioritizing work according to the tasks and activities that are most likely to deliver those benefits. They frequently review factors like customer feedback and market demand, and then manage their delivery resources – the people working on the product – accordingly to ensure they’re also driving toward a product that the market wants.
Good value propositions describe the underlying customer need, the intended approach to create a solution, the intended benefits it should provide, and the distinguishing features that set this product apart from the competition.
4. A culture of enabling, not controlling
Developers, designers and engineers want to feel empowered to make the best possible product. To do this requires help and support for people to do their best work. Great leaders focus less on the bureaucracy of corporate hierarchies and reporting structures and instead do what it takes to make sure that the people who actually do the work have the information they need to do the best job possible.
That means feeding information directly from customers into the product development team’s hands. This also goes back to the earlier point about discovery. Product teams need to feel empowered to experiment, to learn from mistakes, and to react to feedback in the moment.
The desire to create order in software and product development comes from the temptation to have work carefully planned out from start to finish. And while planning is certainly important, it’s a tricky game when there is so little certainty in product development – what good is a plan if it’s full of assumptions and guesswork? The most effective and empowering way to order product development is in short bursts, where developers feel they have the license to respond to feedback in a way that might veer from the plan.
5. Funding capability for the long-term, not short-term projects
Projects are inherently transient. New teams are stood up to deliver a defined scope of work, at a defined budget regardless of how the market moves, a product idea changes or the organizational context shifts. Projects are often used to introduce large amounts of change into the organization, replacing systems and processes in big batches and affecting many people’s roles and responsibilities.
However, today, technology develops at a rapid pace. New software releases happen multiple times a year. It’s not realistic to believe that project-based development can keep pace with such an aggressive release schedule. The funding model needs to take into consideration the core capabilities of the organization, how they’re funded to be operated, and how they’re funded to be continuously developed and improved over the long term.
In a project-based model, it’s too easy for core capabilities and the underlying technology to become old and outdated, allowing others to leapfrog the competition. Longer-term product strategies are required to remain constantly relevant.
Great leaders in product management know how to remove roadblocks and organize teams to optimize the flow of value delivery to the customer. They’re accountable, overseeing all aspects of the product management process, including customer desirability, technical feasibility and business viability. Ultimately, they create a culture in which teams are able to do their best work.
Our next post in this blog series covers how to enable great product management through product managers. You can learn everything you need in our thought paper, “Moving from Projects to Products.” Download the thought paper at this link.
Additional Insights
The art of feedback
Process mining for customer journey mapping
The importance of owning your transformation
