Delivering digital product is a complex process
Teams often start out with a clear idea of what they want to build. They impose structure through models, maps, and frameworks and a plan for the creation of a digital product laid out in a straight line in the form of a Gantt Chart with a clear route from the start to the end of the project. The assumption is that every feature, problem, constraint, risk and solution is known and understood and that to build the end product we simply have to write the code in the order that it’s been laid out.
But in reality, the journey to get to a successful digital product is marked by a series of decisions, trade-offs, problems and ambiguity, that often side-tracks the process. And unfortunately, we humans are rarely prepared for nor very efficient when it comes to dealing with this level of chaos.
The more complex the project, the more we plan
Humans possess a natural emotional response to create a structure where there is ambiguity and so the more complex the project, the greater the temptation to do more planning. Teams focus on a more and more granular analysis of problems that may be as long as 3-6 months away, leading to frequent struggles when the problem then suddenly requires a different solution than the one imagined 3-6 months earlier.
And the more reluctant we are to abandon a plan that has been proven wrong
The reality is that circumstances change and the teams and ways of working that must be able to adapt are not set up in a way that allows an easy and quick change of direction. Worst off are teams and projects that are unwilling or unable to adapt even when continuing on the same path is going to cost more and lead to an unsuccessful outcome. The same plan that was meant to ensure success, now owns them. I’ve seen teams double down on their decisions even when the evidence is clear that they need to change course.
The new norm is based on quick feedback and re-calibration
The most effective teams I have worked with didn’t work off of a traditional plan. There was a list of priorities set by the Product Owner which would change based on new information from the business or feedback from people using the product. Features were released iteratively as working code in production environment from where they could be used and tested by real users. Feedback would then be gathered and the team would adapt and change course based on what they had learnt. This feedback loop was the key driver to being able to test hypotheses and assumptions that had been formed early in the product’s life-cycle.
Other teams use techniques such as mind maps at the beginning of each new sprint to identify the work ahead. This shows the relationship between items but not the order in which they should be built. The team would then discuss the tasks and decide on the best way to design, build and test each as well as how to measure success. Unfortunately, many digital product teams release features or products without a clear idea of what success looks like and how to measure it. This ability, to measure and react to new information, is a key indicator of a highly performing digital product delivery team.
It’s important to point out that these teams were not working completely blind.
In my experience, successful teams have
- Clear business objectives, a North Star based on the end-users’ needs that are shared and understood by everyone on the team,
- The skills, experience, and autonomy to decide on the best way of getting to the agreed outcome, quickly, and
- Frequent and well-described feedback loops that are evaluated objectively and used to steer the decision-making.
Want to know more about how we build digital products or how we can help turn your project into a success?