Joining the dots: Managing strategic dependencies
•Download as PPTX, PDF•
1 like•1,940 views
This document discusses managing strategic dependencies in product management. It defines a strategic dependency as one where the delivery method affects the ability to solve customer problems. It recommends focusing roadmaps on strategy rather than execution details to more easily plan, prioritize and adapt. Strategic conversations should explore dependencies to understand their purpose and whether schedules are truly strategic or not. Considering products as platforms that enable other products brings consistency while separate strategic and execution roadmaps provide flexibility.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Joining the dots: Managing strategic dependencies
Similar to Joining the dots: Managing strategic dependencies (20)
Recently uploaded
Recently uploaded (20)
Joining the dots: Managing strategic dependencies
- 1. Joining the dots: Managing Strategic Dependencies
- 2. Why are PMs asked about dependencies?
- 3. “A dependency is strategic if the way the product is delivered affects the ability to solve the problem”
- 9. Ask why…….
- 10. Ask why……. Short term gain from sales opportunity?
- 11. Ask why……. Short term gain from sales opportunity? Highlight long term pain of “Frankenstein product”
- 13. Ask why……. Control/comfort? Highlight how discovery reduces risk
- 15. Ask why……. For planning? Create a release plan for high confidence changes
- 16. What if the date IS strategic?
- 17. How not to do it…..
- 18. This works! • Easy to understand • Theme-specific • Tied back to objectives
- 19. This works! Doesn’t imply other dates
- 21. Multiple actions required to deliver value
- 22. Why do logistical dependencies happen?
- 24. “A platform is a product which provides value by enabling other products to exist, or by introducing standards and consistency”
- 25. Example: Sponge cake! ● Created as a standalone product ● Provides value by combining with other products ● Brings consistency
- 26. Platform Benefits ● Consistency (functional and UX) ● Reusable components ● Enables multiple modalities
- 27. How do I show platform dependencies?
- 28. How do I show platform dependencies? Separate Strategy from Execution
- 29. Execution-based
- 30. • Multiple roadmaps required to show details • Need to show dependencies in multiple places • Difficult to see all detail in a single view • Difficult to reprioritize Execution-based
- 31. Strategy-based
- 32. Strategy-based • User value easy to understand • All ideas required are visible in a single place, regardless of the teams involved • Easy to re-prioritize • Execution managed separately, once plans are fixed
- 33. Advantages • Changes to project funding/approvals are easier to manage • Value-driven, single roadmap • Lean/agile/flexible • Add/remove scope without large-scale roadmap changes • Easy to spot potential issues
- 34. Summary • Dependency is only strategic if delivery method affects value • Lean (theme-based) roadmaps inspire strategic conversations around what/why • By focusing on strategy, not execution it’s easier to plan, reprioritize, and adapt to your market
Editor's Notes
- Hi Everyone! It’s sad I can’t be there in person with you all, but hopefully this “filmed in the comfort of my own dining room” presentation will still be useful for you! My name is Liz, I’m CCO for ProdPad, and today I’m going to talk to you about dependencies, from the point of view of product management.
- In my experience, PMs are asked about dependencies for a variety of reasons - some of them are strategic in nature, and some are not. Let’s see which is which!
- First of all, I’d like to take the time to determine which dependencies are strategic, and which ones are not.
- Let’s look at time based dependencies first. I think it’s fair to say that strategic milestone dependencies should have a REASON why the date is important. By “reason”, I don’t mean that sales said it would be ready to close the deal! I mean there is a real world event that is determining the importance of the delivery.
- An example might be a new regulation or law, where compliance is required in time for a specific date. A recent example of that was when the European GDPR laws came in. As a Brit, I can tell you that there are a number of companies who are making changes in time for Brexit. These are time based dependencies that are strategic in nature - it’s important to our strategy that we hit those deadlines.
- When developing a new feature or new product, there are reasons why it needs to be done in time for a specific date. If there is reduced value or even increased pain for the recipient of the new feature, it could be seen as a strategic dependency. In this example, our little purple dot bought the cake after the party was finished! It was late and so the cake had reduced value. In this case, there was a strategic dependency - the item was required in time for a specific date, and being late means it can’t be used. Other examples like this might be the delivery of a gig ticket the day after the concert happened - while the ticket might be worth £150 on the night, it’s value the day after is 0 - the time of delivery affects the value. In our world, while cake might be important, it’s more likely that our time dependencies are due to important commercial events. Are you building digital assets for a holiday-related campaign like thanksgiving on a website? Do you need to have that killer feature available in time for an upcoming conference in order to maximise the return on your sponsorship? In both cases, the value of what you’re building is diminished or even completely lost if it’s not on time. There is a strategic decision behind making it a deadline.
- Now, what we often see in the product management world are deadlines which are driven by the fact that sales made a promise, an investor is applying pressure, the leadership team have set an arbitrary date in order to instil urgency. In every case, these dependencies are not strategic in nature. These deadlines don’t affect the likely success of the product, and don’t fit in with the strategy we’ve defined for sustainable success. Don’t get me wrong - if there is a strategic choice made that getting a certain deal is important to sustain the future of the business, that’s fine. But the deadline is then strategic (we have to get the sale, and are aware of what we’re risking by making that choice).
- As such, these dependencies are not strategic. But we all face these pressures on a regular basis, so how do we respond to requests for date in these circumstances?
- The best advice I can give is to put on your product manager hat and ask why.
- Is it to obtain short term gain in order to take advantage of a sales opportunity?
- If so, counter with an explanation of the damage that is done when product decisions are rushed. While the sales team may close that deal, will a poorly judged decision result in a Frankenstein product, or a feature which is suitable for one customer but not the wider market? Is delivering this feature now going to harm the chance of sales making their quotas in the coming months/years? While getting that sale may ultimately become the strategic choice, it’s important that the opportunity cost of doing so is evaluated and discussed.
- Is the request from someone who is attempting to control the product team, or someone who just wants a comfort blanket (yes CTO, of course it will be ready for the end of the month lol)
- In this case, I’d recommend sharing details on how going through discovery reduces the risk of failure. The discovery process itself takes time, and helps us answer questions we don’t know the answers to yet. The fact we don’t know those answers means there is inherent risk attached to any decisions we make early on (such as how we’re solving the problem and when the solution will be ready). By taking a bit more time to nail down the solution, and by avoiding promises we don’t have faith in, we are reducing the risk of failure. When I asked CTOs/CEOs about why they ask for dates, I heard loud and clear that they were trying to anticipate risk - give your CTO/CEO the comfort they need by showing them you’re minimising that risk on their behalf. By building trust with them, they’ll be less likely to pester for dates.
- In the past, I’ve been asked for long term delivery dates in order for project managers/leaders to plan ahead. They want to anticipate whether they’ll need extra people on the team, additional investment or a go to market strategy.
- This is where I’d highlight the difference between a roadmap (which should show strategy) and a release plan (which is a project management artefact designed to facilitate planning). In the latter case, using a gantt chart or timeline is fine - the scope is well defined, resources are understood and there is a project manager in charge of communicating changes. We’re talking about communication of short term plans based on current knowledge. Where the plans are fuzzy, there are lots of unknowns and discovery is underway, any plan with dates on is essentially a lie you’re telling your boss. Harsh, but true.
- As an alternative to milestone or time-based dependencies, I’d like to talk about logistical dependencies. These are particularly important for platform products, as we’re talking about the need to provide benefit to the end user as a result of the combination of two or more deliveries. In this example, there is no value until all the related changes have happened - for example, the robot has both body and legs, or the device has both hardware and software. Either component on its own doesn’t have value - it’s the combination of the two that is resulting in end user value.
- So it’s clear by now that I like cake analogies (I mean, to be honest, I just like cake!) However, a cake is a good example of a platform product. It’s a product in its own right - I can sell sponge cake on its own, maybe in a B2B sense, to be component in someone else’s cake. It can provide value in different ways, depending on how it’s combined with other products like icing, toppings, cream, fruit. And it provides consistency - regardless of what the toppings & fillings are, I know that the cake will always do the job of providing structure to the final product.
- Platform products are the same - they provide a consistent way of solving a problem and they make it easier for other teams to create different products without reinventing the wheel
- The question is, when I am planning a roadmap for a platform product, how do I show dependencies? How do I ensure that I can show the strategy for my platform, and for the products it enables and make it clear when a change in one product affects another.
- In my role as CCO at ProdPad, I see a lot of roadmaps, and advise on best practice. What I frequently see are roadmaps which are split into teams - one roadmap for each delivery team. One team is responsible for the API, or backend components, and one team is responsible for the product as it is delivered to the customer. There is a need to add detail to each item on the roadmap to show it’s dependent on another piece of work.
- There are a bunch of problems with this approach (as per slide)
- I prefer a different approach, and that is to structure roadmaps in terms of the ultimate value they provide to the end user. Platform teams who are working on platform components are ultimately doing so to ensure there is value to the user - or at least, they should be! In this example, the end user needs the analytics dashboard so they can see data in an actionable form - that’s the problem we’re solving. Some of the work that needs to be done is to work on the back end infrastructure (the infrastructure team) and some is being done on areas of the product managed by the front end team. However, we’re expressing all the work in a single, combined initiative - and we no longer need to worry about showing dependencies (other than maybe the order in which the changes appear in the list). This is a strategic view - it shows what’s being done in order to solve the problem.
- And there are other advantages too -