Deliver big bet initiatives
10 Learnings on Delivering Innovative Products at Scale
Delivering features, experimental products and solving small, well-defined problems are relatively straightforward product development. What about delivering big bet initiatives, major solutions, and modernisation attempts that can be complex and involve multiple stakeholders from inside and outside of your organisation?
I’m currently working on a product modernisation for a system that has been running for nearly 40 years. 🫣🫠 Now, here’s what I learn:
Be a vitamin and a painkiller.
Conventional wisdom is to choose to build one or the other, but it does not have to be binary thinking. A great product does both; necessary short-term fixes to pressing issues and long-term benefits that address general health, or even better, to come up with cures that make the problems disappear entirely. 💊
Because no matter how efficient or capable the engineering team is, the numbers will show if the initial product idea is flawed. Great teams know they have to go slow to go fast. I’d ensure we get the correct information, work on our product conviction and have our north star metric in place to guide our day-to-day product decisions. No one wants to build the wrong product or face the frustrations of re-work and wastage. This is where agile can come in to help us learn and iterate early.
Neither overestimation nor underestimation is good.
Underestimation leads to scope cuts, delays or an understaffed team trying to achieve the impossible. Overestimation can cause resistance from leadership to approve a funding/project.
As engineering and product leaders, we tend to make early estimates that are very optimistic. Examined from two distinguished scholars’ points of view, most people tend to see the world through rose-coloured glasses resulting in leaders’ delusions of success from flawed decision-making. 🧐
Also, there are other tools for legacy modernisation other than minimum viable product (MVP). The endowment effect and loss aversion phenomena are so natural we’ll need to find the shortest path to value, decompose and segment them into estimable chunks of value rather than a big-bang replacement (which is not quite an MVP anymore).
Sequencing becomes a lot more critical.
In large-scale innovative product launches, we work over a longer time horizon, with more moving pieces and complex relationships between tasks. We need to orchestrate more teams; many sit outside of our function. This creates more dependencies in what gets done and when.
Both existing methodologies (Agile and Waterfall) don’t quite provide the right environment or tools for sequencing dynamic delivery plans. Some say agile is too short-term and lacks enough foresight to make external commitments and secure resources. Some say waterfall is too rigid, requiring immense detail before work can begin and failing to adjust as we learn more over time.
In most delivery plans, teams do have milestones in them. But we run into challenges frequently because we choose high-level milestones that aren’t meaningful. Robust delivery plans should have milestones that indicate layers of fidelity for each of the significant blocks of work in our Work Breakdown Structure, such as demo ready, fish food ready, dog food ready, and launch ready.
Status updates can be meaningless.
Milestones should give everyone a point of reference on whether the product development process is on track or off track and how far ahead or behind. Hearing or seeing reports that the work is “green” doesn’t tell much. ✅ I’d rather see the progress demonstrated in a functional output.
If someone asks a high-level question like, “how is the product development going?” I’d want to avoid going into detail on the status of each work item and all the remaining things to work on. They’ll get lost in detail, which might also mean little to them. Instead, identifying interim outputs that break these high-level milestones into smaller output components provides more detail for leveraging the delivery plan.
When we under-invest in structuring interim outputs in our development plans, we could miss out on a milestone that is off track due to the lack of detailed understanding of the leading indicators. We may also wait too long to integrate work, creating risk towards the end of the development cycle. Developing interim outputs requires additional time to synthesise the current state, put work into staging or otherwise get things in a sharable format. These interim outputs add unplanned, net-new work to our process when not budgeted for from the beginning. 💸
Make tradeoff decisions early.
Instead of pushing forward with a very optimistic plan, I’d make difficult tradeoff decisions early in the process. The system anchors on three product development constraints: Scope, Time, and Resources. Consider these tradeoff options in the early stages of project planning. Scope: reduce the number of features, reduce the complexity of features, reduce the quality of features, and reduce the number of priority segments. Time: move launch dates, reduce time spent on QA and Testing, and shift work to post-launch. Resources: add more resources. 🪂🪂🪂
Because quality doesn’t exist explicitly in the iron triangle of project management, thus, it’s the first to sacrifice because out of sight, out of mind. And if budget allows, the first thing that comes to most people’s minds is to add resources. Adding more resources is a great option early in the lifecycle of a project for work that is isolated in its own file or in an isolated customer experience. However, not all work can be accelerated by adding more people, as illustrated by the classic nine months for babies to grow and develop. Similarly, when teams write code in the same files, we often don’t get faster or accomplish more scope with more people. We also can’t accelerate the work if there are dependencies with a centralised team. And if we’re already late in the project, it would take way too long to get new resources up to speed to add value. Read this timeless book: The Mythical Man-Month.
Additionally, firefighting is a vicious cycle. The mindset that we will overclock ourselves and get it done comes from a good place but is not sustainable for a large-scale project. People get burnout, which often turns into a toxic culture, making folks think that skipping lunch, working late, attending multiple meetings, and being busy is a badge of honour. This increasingly vicious cycle creates a cascading resource constraint and forces leaders to put out one fire after another. 🧑🚒
Adjust for dependencies.
When we look across the sources of dependencies, we first want to pay attention to dependencies from teams that we don’t directly influence. These teams become our “dependency teams”, requiring thoughtful collaboration throughout development. To adjust for this dependency, we want to change the sequence of work so that we can still progress on other aspects. Or, if they require something from us — like APIs or access to the pipeline — we want to adjust our approach so that these things are ready when needed.
The second would be the long poles in our development process. ⛺️ Organisations using an Agile approach often encounter problems with “Long Poles” when estimating work. Long poles are the ones that take the most extended amount of time from start to finish; it could be a technical infrastructure complexity. We may need to dive deeply into the back-end work before making meaningful progress in the front end. Long poles create the most complicated dependencies and the most risk. Thus we want to allocate work to get visibility on them as early as possible. Should the product development requires integration with a 3rd party, these 3rd party requirements are the long pole dependency in the project. ⚠️ We’ll likely ship late if we encounter a long pole dependency late in the project.
Mitigate the risks.
The careful and thorough planning of WWII D-Day: Normandy invasion had several vital missions. One of those missions was the capture of Pointe du Hoc — scale the 100 feet cliffs before dawn and neutralise enemy positions atop Pointe du Hoc. 🧗 It was a disaster. Choppy weather caused the rangers’ climbing ropes to become extremely wet, increasing their weight and making it difficult for the rocket-fired ropes to make it to the cliffs and take hold. In the end, the rangers suffered a seventy percent casualty rate. 🤕
This tells us overplanning doesn’t always guarantee success, but thinking ahead will help us make crucial decisions later. We can mitigate the risk of failure by using if/then modelling and considering backup plans. By putting in the effort to think through the different scenarios, we’ll avoid having to make those critical decisions when we’re taking fire and under a lot of stress. 😫
Leverage Elon Musk’s employee vector theory.
Learn from Dharmesh Shah (Founder of HubSpot) and Elon Musk how to make more progress with the amazing people we already have simply by better aligning vectors.
“Every person in your company is a vector. Your progress is determined by the sum of all vectors.” — Elon Musk.
The TL;DR version is to think of all our employees as vectors: First, assess them to see if they’re aligned in the same direction. Second, evaluate their value (i.e. performance). As leaders, ensure they’re all pointed the right way and that we’re addressing low-performance issues.
When we have perfectly awesome people, but they’re perfectly misaligned, the result is zero (null vector). If they’re all heading in different directions, we get sub-optimal impact. Imagine if they’re all heading in the same direction, we get maximum impact! 🙌
Use Sun Tzu’s Art of War in communication.
There are many ways to communicate with team members and external partners, but when the time comes to give instructions, as leaders, we are responsible for ensuring that our instructions are clear to them (not theirs).
“If words of command are not clear and distinct, if orders are not thoroughly understood, the general is to blame. But if his orders are clear, and the soldiers nevertheless disobey, then it is the fault of their officers.” — Sun Tzu, Art of War.
Apart from clear, understandable communication, documentation is equally important to convey that, especially when working with external partners. A prevalent need for big bet initiatives is launch checklists. ☑︎ These checklists are co-created by product, engineering, support, other departments, and not to forget external partners as well. The goal is to define who does what at a particular time and in what order.
Move from event thinking to system thinking.
From an event thinking perspective, it focuses on short-term solutions to specific events, often leading to ineffective solutions and unintended consequences. On the other hand, systems thinking involves:
- Looking at the entire system.
- Understanding the underlying structures and feedback loops.
- Identifying the root causes of problems and the long-term effects of any solutions implemented.
It is necessary to look beyond actual surface-level events into the patterns of behaviour, systemic structures, mental models, and vision. Our ability to influence the future increases as we move from the level of events to vision. Most people don’t resist change; they resist being changed when it’s imposed from the outside. As we go higher up the levels, we may not have direct influence and control over these changes. That’s when we might need to escalate to seek help and support from the right folks. 🧝 🥷 🤖
And that’s the 10 learnings about delivering innovative products at scale. Agile is not a silver bullet; it doesn’t address unrealistic deadlines and many others. Pick a framework/methodology that best increases your chance of success and adapts the execution with the mental models and learnings you have garnered. Delivering big bets is not easy, but we can do it! 💪 🙌
A fun bonus bit: Have you ever navigated through bureaucratic nightmares where devilish incompetence masquerades as due diligence? Not all are due to human failings; conspiracy-minded folks are forgiven if they quote this once top-secret Simple Sabotage Field Manual, written in 1944 by the CIA’s precursor, the Office of Strategic Services (OSS). Just for laughs. 🤣
If you like what you read, be sure to hit that 👏 button below and share. It’ll motivate me to write more. Thanks! 😍
