Three Impediments to Overcome When Executing Digital Product Builds
By Aditya Saxena — Expert Associate Partner, Deepak Joshi — Principal Product Manager, and Pallavi Misra — Product Specialist II, Build by McKinsey
Congratulations! The management team is impressed with your product vision and idea, and it has approved the budget to execute the idea. The idea is among the top three priorities for your organization this quarter, and the plan is to launch it in the market by next quarter. This is terrific and much-awaited news! Now starts your journey to convert your idea into reality. But here is a glaring fact that stares at you. According to research published in 2021¹, there are over 30,000 new products introduced every year (physical and digital), and 95% fail, telling us that converting product ideas into reality is no cakewalk. The impact of failed or delayed product builds isn’t only financial. There are significant non-monetary implications for teams and organizations, including decreased team morale and focus, diminished stakeholder confidence and interest, customer acquisition delays and their resultant poor feedback, and products falling behind the competition.
Enterprises are continuing to embrace tech and digital as core components of their business at an ever-increasing pace. And, as the investments in these areas increase, enterprises need to be ever more cautious to drive the desired results from these investments. In this article, we will share our learnings from helping multiple clients in their journey to build successful digital products and businesses.
Three impediments we have seen over and over again while executing Product Builds:
Being aware of these three impediments will help the owners of digital products at enterprises, from product leaders and product managers to delivery leaders and product owners, to avoid the most common traps which can lead to inefficient digital builds and proactively find ways to mitigate them. Let’s dive in.
1. Unclear requirements: This is one of the most common causes for delays which affect the success of a product launch. Poor clarity on requirements can sprout from multiple sources, including:
- Product vision clarity: If not articulated, socialized, or aligned with stakeholders, this can lead to frequent conflicts and misunderstandings on scope and context. To mitigate this, share and discuss the overall product vision whenever a new team member/stakeholder is onboarded. The product vision can be articulated through various methods, as simple as filling a future press release template or product canvas. A strong sign that the vision is understood comes when team members ask questions such as — ‘How do you think this feature helps us achieve our vision?’
- Functional requirement — quality assurance and management: Poor quality requirements often include unqualified assumptions and incorrect or insufficient details needed to execute a requirement. This leads to a lot of rework and developer frustration. A Definition of Ready (DoR) could help mitigate this. The entire team should align on a DoR that should be met before development begins, including everything from the format of requirement (Gherkin vs. Regular) and design readiness to developer input and stakeholder sign-off. Sometimes, different developers are working on multiple versions of the same requirement. Do you get questions from your development team such as — “But Figma shows this user journey, so that’s how I have implemented it!” To handle this, you should have a single source of truth using a backlog management tool that suits your requirements and set up processes to ensure that changes are curtailed and clearly communicated. These are just some good practices to ensure that the requirements are aligned before the development team starts on that piece of coding and the teams should feel free to find ways that help them stay aligned.
- Technical requirements’ consideration: It is key to consider and manage a product’s technical requirements to avoid any unpleasant surprises. There are two key aspects here. The first is quality, including code quality, security aspects, performance, etc. The likes of coverage and code smells for the quality aspects should be defined and agreed upon in a ‘Definition of done’ with the stakeholders. Any story should be marked as done only if it meets all the quality bars. The second aspect is to ensure a technical runway supporting the development of the functional elements. These tech requirements often involve multiple teams so should be replicated and prioritized across the backlogs of other teams. Time should also be built in to convince and influence these other team members (more on this in later articles).
2. Poor planning: The lack of a plan is the beginning of software development going wrong and is akin to accepting failure. As they say, fail to prepare, prepare to fail. Irrespective of the uncertainties and moving parts in the product development process, planning is essential to ensure that all stakeholders and team members know what they are doing, when they are supposed to do it, and who is responsible for what. Some key aspects to consider while planning includes the following:
- Iterative Planning: When your leadership asks, ‘When can we go live with this?’ the answer should not be, ‘Development will be complete on this date, marketing will then produce a plan on this, and then…’. You should have a clear, up-to-date, comprehensive plan to share with leadership regularly and ad-hoc. A plan should not be limited to development sprints; it should cut through all key workstreams/functions needed to make the product live i.e., customer service setup, marketing communication, design, etc. By comprehensive planning, we do not mean trying to have every detail about the product requirement before starting. In fact, most products inevitably start from unclear requirements, but having a plan and vision is a must-have so that your team is anchored to the tasks and timelines and continues to iterate on them regularly.
- Metric-driven predictability: Product and program managers should be able to identify potential timeline deviations and plan based on team capacity using metrics and methods like burndown charts, velocity, and capacity. Metrics should be available for the leadership and team to view as needed and should be discussed in Sprint review.
- Launch strategy and success metrics: Defining and implementing these success metrics is essential for continuously striving for product-market fit. The development should ensure the plan and requirements are geared towards achieving the defined metrics. This includes determining success in terms of key metrics when the product/feature is launched, in the short-term and the long term e.g., adoption, activation, conversion, bug reports, customer reviews etc. We can imagine some agile advocates jumping off their chairs and suggesting that this level of planning is anti-agile. We believe that planning (if it is done with the correct input from various dependent teams) does not need to delay the execution. The right amount of planning and the right stakeholders can significantly de-risk execution and timelines, allowing to surface gaps in the plan early on.
3. Siloed operating model: While the agile mindset and Scrum or Kanban form the backbone of the processes, some process areas require deliberate effort to keep the product development process smooth and enable the team members to function effectively. It’s vitally important to consider each of the following to ensure the best possible chance of success for your next product development cycle.
- Co-creating with users: Imagine only receiving user feedback at the end of a build cycle as a part of a standalone UAT (user acceptance testing) and hearing ‘This is not what I meant when I said….’ Not only would this be hugely frustrating after a potentially long and drawn-out development cycle, but this can lead to significant delays, as ignoring these inputs can lead to low adoption later. Mechanisms should be set up to obtain and incorporate user inputs regularly, so they are baked into the sprint cadence from sprint 1. This can be achieved by creating a small panel with existing or potential users. This panel can be invited to demos, and immersion sessions each sprint to get the user’s thoughts on a regular basis.
- Cross-functional, goal-focused collaboration: Team mindset becomes critically important in the setup where new teams are formed to deliver on a mission. It is important for the team to establish a common ground concerning individual working styles, roles, responsibilities, learning goals, and aspirations, with the focus being on the mission that they are set together to achieve. A mechanism should be set up to obtain and incorporate inputs from all related teams/departments (marketing/finance/legal) regularly so that their insights are baked into the product right from the start. For example: Inviting members from different departments during the demos to represent their teams and getting their feedback on what is already built and the upcoming planned implementation.
- Continuous improvement: In the rush to deliver, sometimes the teams skip ceremonies like retrospectives, which enable them to pause, reflect and learn from their mistakes and achievements and accordingly adapt the operating model. Actions should be identified out of each retrospective, along with owners for each action, and the action items should be part of a sprint’s plan and objectives. And all this can be done while keeping the retrospectives fun.
While the context of all organizations and digital builds may differ, identifying and mitigating these impediments early will help you ensure that the digital build goes as planned in delivering the desired outcomes. This will help you save not only monetary costs but also the confidence of your team, stakeholders, and customers.
In addition to being aware of these three common impediments and their mitigation strategies, here are a few key skills to have as a Product Manager for successful product builds: What separates top product managers from the rest of the pack?. We look forward to sharing our learnings from our experience in helping companies with their product builds in a series of articles such as below:
1. Holistic value maximization in product builds.
2. Team aspects of a Product build.
3. Web3 architecture layers and choices.
4. Single vs. multi-app strategy — Imperatives and Implications.
5. Gen AI toolkit for Product Owners
Please do share with us your thoughts and experience on how you have mitigated some of the challenges we have outlined above in your product builds.
Reference:
