Phase II: Process Focus

The second phase is traditionally combined with Phase 1, with a product owner in charge of both phases. This isn’t optimal as it’s hard to find a senior product owner who is able to span both phases, so I have made journey development a phase on its own in the book.

One reason it’s hard to find someone conversant with both phases is that the skills required are different. In Phase 1, the skills have to do with human-centred design or design thinking; asking fundamental questions about customers and their behaviour to uncover the insights needed for experience and/or innovation breakthroughs. This is coupled with knowledge of how profit is made.

In Phase 2, the skills are firstly about designing the process of fulfilment, identifying the right inputs and outputs (mostly data points that are needed, and processing of those inputs for onboarding or transacting), and reducing friction; and secondly about designing a user interface that embodies both the experience and process envisaged. In my concept-to-code methodology, it is the Phase 2 team that has primacy for interpreting the product, service and business model requirements generated in Phase 1, and translating them into stories that allow the software development team to produce code aligned to these requirements with as few mistakes as possible.

This usually involves mapping the journey, identifying the correct data inputs and any outputs needed for decision making, asking for information in the right order, and ensuring that instructions and output shown to the customer are clear. Once the journey maps are sufficiently well-defined, user interface design can begin in parallel, but close synchronisation between the two streams of work needs to be maintained throughout.

A final recommendation is to embed experienced user interface software engineers into the UX/UI design team. This will shorten the discovery time of design complexities that are better dealt with in the design phase than in the software development phase.

Phase III: Development Focus

As the digital leader for any initiative or transformation, it is critical that you understand the foundations of design thinking, Lean and Agile.

The output of Phase 1 feeds the stories that are the input for Phase 3. If Phase 1 is about customers and business (design thinking), and Phase 2 is about internal processes and user interface optimisation (Lean processes), Phase 3 is about Agile software development.

The power of design thinking lies in its foundation in human-centric design, and understanding what customers need to do their jobs well. This is especially important in industries and organisations that are product-centric because they can’t help themselves but start with the product and their business objective first.

Lean has manufacturing origins, and to me the power is the focus on less hand-offs and finding the most efficient way to do something. When you combine this with design thinking, you not only get a faster and cheaper process, but also one that the customer can easily appreciate and understand.

With Agile, you break the development into modules instead of developing the entire code in one go, which was how software was traditionally developed; all the code would be developed and tested, then debugged in one release, and the next release repeats the whole process. The power of the Agile method lies in its ability to make adjustments along the way, something very useful in contexts that are uncertain and where you are continuously refining and adjusting to customer feedback, competitor reactions and industry changes. This fits the hyper-competitive situation in today’s business environment much better than monolithic development and has the additional advantage of being able to support many frequent smaller releases in a year, reducing risks and achieving better time to market.

Also, instead of each team looking at things sequentially, teams are multidisciplinary, comprising people from business, IT, operations, service, compliance, who work together across all three phases, and make decisions as a cross-functional unit to deliver the required outcomes. So more latitude is given to the teams to take an experimental approach.