Embrace uncertainty through a “just enough” approach to product strategy

A common anti-pattern in the world of software development is the over-operationalisation of the research and development process. In moving away from traditional ways of working, companies will spin up long-lived teams, working to sprint cycles, but still find a way to cram an inordinate amount of upfront planning into the system, causing a significant amount of waste. This can feel like a big step in the right direction but often comes with very little benefits compared to the old way of working, as the way the team works doesn’t change.

Teams should embrace uncertainty and experimentation by implementing a just enough approach to strategy and ideation.

“Just enough” roadmaps

Roadmaps should not be long lists of thoroughly defined features and tasks. As great as it would be to have a bulletproof, long-term plan for your business, this is rarely achievable. Instead, backlogged initiatives should be less thoroughly defined the further they are from implementation. This ensures that:

• Cost to pivot. The cost to pivot is much lower when distant roadmap items are thought of as future opportunities and ideas rather than pre-defined scopes of work scheduled for future completion. New learnings often suggest that you should abandon a large chunk of your planned roadmap in favour of a new set of initiatives.
• Avoid sunk-costs. Time spent detailing future work that may never actually be delivered is unrecoverable. This time could be better spent on other work. Additionally, individuals who’ve invested big chunks of time in scoping features will be biased towards having those features built. This could lead to inertia in situations where agility (i.e., ability to pivot) is critical.
• Pre-defined scopes are usually bloated. When the planning process is decoupled from the delivery process, one’s eyes can be bigger than one’s stomach. This usually leads to unnecessarily large scopes of work for the real problem at hand. Outputs are then prioritised over outcomes.
• Manage expectations. Gluttonous, pre-defined scopes of work, have a way of getting around. Internal and external stakeholders get attached to specific implementation details, and any future cutting of scope leads to disappointment. By making future work explicitly tentative and broad, stakeholders can be focused on the problems being solved rather than the bells and whistles.
• Encourage creativity. Upfront planning is usually done in a silo by product managers and designers. Even if they try to be as consultative as possible, the engineers who will eventually execute the scope of work are rarely available to sink their teeth into the scoping process for work that won’t be tackled any time soon. By leaving planning until much later, engineers can be much more involved in the process. This will not only lead to better outcomes in the short term, but it will also foster a more innovative environment where engineers are very engaged in the why and how of what they build (as opposed to simply churning out code).

You still need a plan

It’s still important to know what’s next and to have a North Star for your product. Here are some tips for providing direction without being overly wasteful or prescriptive.

• Start with a simple but ambitious mission. Everything your company tackles should be tied to a one-sentence mission that is easy to remember and understand. For example, Google’s mission is to organize the world’s information and make it universally accessible and useful.
• Set a vision for the upcoming period. This could be a goal for the next couple of years or more and should represent a major milestone or step-change for the company. For Google, it might be to become the #1 generalised search engine on the internet. I like to scaffold these goals with specific success measures (e.g., customer count, growth rate, NPS). Again, this should be succinct, easy to remember, and easy to understand.
• Outline your strategy. Enumerate the high-level initiatives that you believe are required in order to achieve the vision. I like to define these as problems to be solved. If the problem isn’t well-defined, and relevant to your vision, it probably doesn’t belong in your strategy.
• Solution near-term initiatives. While most initiatives should simply represent problems you want to solve in the future, your team may require some guidance to determine how a problem should be tackled. If this is the case, some solutioning should be carried out for initiatives that you expect to tackle soon. A definition of ready for initiatives can help this process.

Using the framework above, the more near term a piece of work is, the more clearly defined it is. The mission is broad, the vision is less so, the strategy has explicit steps (but with open-minded solutions) and upcoming initiative have some high-level solutioning. The goal is to ensure the company has direction, and that when an initiative is picked up it is ready to be ideated and delivered by the team.

I typically leave greater levels of fidelity to the team (e.g., epics, stories, spikes, and tasks), but these should also be defined only when required.

Tactics

The scoping and decision-making process can be greatly simplified if common decisions can be standardised. A high level of standardisation will make planning more rapid and therefore reduce the amount of time required to scope upcoming work. Conversely, standardisation will reduce creativity and out-of-the-box thinking, so it is absolutely possible to go too far.

• Design principles. One way to simplify the decision-making process is to be explicit about what is important to the team. This can be done through designs principles (both UX and technical). Example design principles include API-first, mobile-first and dogfooding.
• Technical patterns and foundations. Teams will likely face the same technical problems multiple times. By building internal foundations (e.g., SDKs, automation, and infrastructure-as-code) upfront, you can reduce future decision making and development effort.
• Design patterns. Teams will also likely face the same user experience challenges multiple times. Building design guidelines and a component library can significantly simplify the user interface design process and enable teams to get straight to execution.

Supplement planning with research and experimentation

A just enough approach to strategy and ideation can feel a bit like shooting from the hip. This is especially true when future initiatives have a significant level of uncertainty around implementation. In scenarios where future initiatives feel especially daunting because the solution is not obvious, research and experimentation should be embraced. Teams can bring forward experiments and research (e.g., technical proof of concepts, customer research, UX prototypes) relevant to future initiatives in order to gain some early confidence in how a problem can be tackled.