Design Thinking for Product Management

Head of Product
In July 2017, a recruiter called me up and I jumped at the chance to be Head of Product at a health insurance & wellness start-up — in Sydney, Australia! This particular “start-up” is actually being incubated under the umbrella of one of the country’s most trusted consumer brands, with strong customer relationships and marketing reach into over 50% of Australian households. It felt like a dream come true to define and deliver innovative digital solutions with a small, co-located team, as an equal member of the leadership team alongside Heads of Marketing, Tech, Sales & Operations, Finance and Commercial. The company as a whole hovered around 65 employees, while the Product team I managed comprised two Product Managers, two UX Designers, two Visual Designers and a Product Analyst. For any given initiative, we would be tightly interwoven into virtual teams typically with Marketing, Tech and Commercial colleagues.

This preface provides context for sharing one of the most significant impacts I made in this organization — the ratification of a design-thinking based, strategic product management process. When I first joined this highly agile company, it was still operating in a mode that most informed by implementing against initial business hypotheses using Lean approaches. The roadmap wasn’t defined and there was a big backlog of intentions that weren’t clearly defined. The Product team was struggling to prioritize the big “rocks”, and the UX team was focused more on resolving customer pain points of incremental value rather than helping to define desirable solutions.

Double Diamond Model for Product Management
I firmly believe that the best Product Management approaches put users at the heart of all decisions, always of course balanced against business viability and tech feasibility. Strategically delivering quality user experiences is the ultimate formula for product success. Using customer-centric research techniques, teams can quickly identify real-world needs and validate early concepts before investing in costly cycles of development and delivery. Early discovery work fundamentally allows viability and feasibility to manifest right alongside customer desirability. Even the most agile software development involves very significant costs to launch solutions to the market. Having an “MVP” (minimum viable product) mindset seems like a way to avoid these costs, but most of the time it’s a trap filled with software hacks that just shift the burden of ongoing design and refinement further down the road.

So, I brought in a design thinking-based approach, aka the “double diamond” model, to rationalize business strategies against user needs, allowing early market investigation and concept validation to lead into further design refinement and then development and delivery of quality solutions.“Design thinking” is generally sweeping the business world, as the powerfully iterative and effective methods of design are made sensible for leaders of product development. This double diamond model has been used at major practices like the Design Council in Britain and the Digital Transformation Office of the Australian government, where my friend Leisa Reichelt practiced until recently, as well as well-known consultancies like Adaptive Path which was purchased by CapitalOne.

As you can see from the diagram, a hunch or intention in the organization (with its origins in any team, from Marketing to Sales & Operation to Tech to Commercial to, of course, Product) is formulated as a problem statement and high-level business model canvas for the Initiative Brief. Then teams, as collaboratively or asynchronously as needed, get to work in the Discover phase. This is where we invest in thoroughly understanding the competitive pressures, market forces and most importantly, user perspectives and needs that will inform a desirable solution. The Define phase involves formulating a strong hypothesis for action and testing potential solution directions — converging towards a feasible solution. The resulting product work is wrapped up in the Product Plan, that passes through a key stage-gate with all the key stakeholders. Only when the plan has sufficient desirability and feasibility defined is it allowed to move into the agile development process. In Develop and Deliver phases, the teams are writing epics and user stories and applying all the lovely ceremonies that turn the original intention, now fully defined and validated, into a completely viable and quality deliverable.

It’s like, magic! Very hard, very challenging, very complex, and very rewarding magic.

 

Impacts and Retrospection
My high-powered Product team was ecstatic to have a more clearly-defined and significant role to play in the definition and formation of product solutions. We didn’t bring in too much process or create too much documentation — but we did have more than zero. We set ourselves a significant challenge in operating both more in the forefront and more deeply during the Discover & Define phases, while continuing to maintain a firm guiding hand on scope and prioritization during the Develop & Deliver phases. This juggling act requires a great working relationship with our partners in Tech and the rest of the organization, including good habits of communication, trust, and reliance on agile ceremonies.

I look forward to talking to more product managers and further sharing and examining UX strategies and practices with a critical eye. This is one job that is never done.