Design Thinking in Product Processes: The Double Diamond framework
Last week I gave a talk about Design Thinking in Product Processes in an Athens meetup organized by the great folks at Product School and it was about the product process that we were following at Contentful, an innovation design framework by the British Design Council which was adapted to our process from the great design minds I had the pleasure to work with, Janko Jovanovic and Ben Lowdon.
The Slide Deck can be viewed here:
and the transcript follows. Hit me up on twitter, if you have any questions, comments or would like any help or advice on PM stuff.
Slide #2 - Introductions
Starting with a quick introduction of who I am and tricking you into believing that I know what I’m going to be talking about for the next 30’. I worked at Daily Secret with Savvas as a Head of Design, then moved to Edenspiekermann in Berlin where I worked as a UI Engineer before making the jump to a Product Management gig at Contentful and then moved back to Greece where I’m now working at Lenses, a dataops enterprise product.
Slide #4 - The framework
Here it is in its whole glory. It is just a framework to help you balance your discovery task and delivery tasks.
It is a marriage of product process and design thinking and was introduced by my smart colleagues at Contentful into our process. It consists of 2 main phases: Discovery and Delivery with each breaking further down into a diverge and converge phase.
Slide #6 - An example from Contentful
So, let’s take it for a spin. There is no better way to show it by giving you an example of how we applied it at Contentful.
“We need Content Workflows”
This is not a user story or a jtbd, it’s something though that the entire organization has been collectively knowing that we were missing, for years. A lot of customers were asking for this, we were losing deals, getting hammered by the competition and that we finally decided to take action as the time had come based on our company’s strategy.
Slide #7 - Explore
So, with starting with this item we started exploring the problem area:
What does Content Workflow mean in terms of user needs?
What does the competition do?
How much does this hurt us, business-wise?
What are the current alternatives our customers are using
What are our stakeholders saying?
Slide #8 - Explore
This took about 2 months, while the development team was busy wrapping up the previous project, me and my product designer talked to about 10 enterprise customers, did extensive competitive analysis of 10+ competitors, held a workshop with 20 people from our sales, customer success, support departments, solution architects, sales engineers and talked to stakeholders.
Slide #9 - Explore
At the end of this phase we had, without exaggeration, hundreds of post-its with customer insights, a wiki page with a competitive analysis and video recordings of customer interviews.
Slide #10 - Explore
Even though we waited for the next phase to come up to conclusions we could already see a couple of trends emerging from all these insights.
Every major competitor was playing on a level field. They were all doing the traditional workflows thing with the different content states.
Workflows were more of an RFP feature that was requested by the CMO. The actual content creators craved for an easier way to communicate with content experts to get some help, review or action on their content piece.
This is already smelling like a good way to solve an important problem in a way that was different from the competition.
Slide #11 - Define
Now it was time to turn that mess into a meaningful thing, a single focused problem to solve. And if your team is autonomous enough (like a “product team” compared to a “feature team”) then this is where your job would mostly end.
Slide #12 - Define
In the end, we created this opportunity canvas which listed information such as: the problem statement, the metrics, the target personas, the marketing release strategy, the effort, the business value. We used this format because it was easy to share across the entire org and provide the gist and it was also a single artifact that we used in our weekly product kanban meeting where we shared updates with the company.
Slide #13 - Define
This is what our product kanban looked like, btw, which really helped communicate what each team was doing each week to the rest of the organization by mapping their own projects in their canvases on the board.
Slide #14 - Define
If you want, you can use your own template that works better in your organization.
Slide #15 - Define
Or you can use a fake Press Release, like Amazon does, or a User Story Map which shows the problem in a journey format. It’s really up to you and you can get really creative, like make a video or a prototype that illustrates your problem. Remember, this is your domain and this is one of your most important deliverables.
Slide #16 - A good problem statement
Whatever you do, make sure that your problem definition has these attributes.
Solution agnostic
User focused
Business-impactful
Measurable
Inspiring
Slide #17 - Prototype
Then we switched to prototype mode. Exercises like design studios and other co-creation workshops help you to get as many angles to the solution as possible. We then went with invision click-through prototypes and kept a feedback analysis grid to make sure that our biases didn’t play into deciding what the best solution is. I don’t have an actual screenshot of the artifact or from the user-testing process, but what we did was talk to the customers whose problems we had documented in the first phase and got back to them with “hey, remember that problem that you reported 1 year ago? We have a possible solution. Wanna participate in a 30’ test session?”
Slide #18 - Prototype
Finally, after a couple of iterations, we came up with a solution which we described in two ways. An invision click-through prototype which showed the high-level interactions of the feature itself and a story map which described all the touch points before, during and after the usage of the feature by a user, such as onboarding, documentation, showing status in other screens.
By the way, he solution was nothing like what every competitor is doing, which is providing different content stages, but we provided a smaller and more flexible unit of work which solves the core problem but allows more versatile use cases without blocking the flow: Tasks. This was spot on aligned with our vision of content automation and we couldn’t have gone with the traditional workflows steps if we wanted to offer the programmatic flexibility that we wanted with that traditional feature.
Slide #19 - Deliver
Finally, this is the last step of the process and the longest and most expensive one. Here the entire team is involved in delivering the feature, working in Scrum and...there’s not much that a PM can do here. Maybe, depending on your organization you might have to put on your Project Manager hat here.
Slide #20 - Waterfall much?
Now, you might be wondering if this is waterfall. “Aren’t we supposed to be working together, developers, designers, POs?”. “Are we not generating too much waste?”
Slide #21 - Waterfall much?
Well, here it depends on what you mean by “working together”. If it is about the entire team working into the discovery phase by running workshops, talking to customers, synthesizing interviews, then HELL YEAH, definitely work together - this is also encouraged by our Scrum sages who suggest we get rid of titles within the team. Mind you, we are talking about the activities that are defined in the first 3 parts, though, not the last part, and you know why?
Slide #22 - Real time
If we were to map the process into a time axis, the shapes would be skewed like that. Because the investment that you are going to spend, even if your entire team is working on these, is completely disproportionate with the cost of working on the 4th step.
Slide #23 - Real time
If you jump as a team right into the delivery phase based on a senior executive’s gut feeling, a well-intended support coleague’s reported customer problem, or a direct ask of a PM without having done your due diligence, I guarantee you that you will have gaps in your understanding and will have to stop and restart so many times that in the end your developers will give up and be like “just tell me what you want me to build and I’ll do it”. Problems transfer easily, solutions don’t.
Slide #24 - Real time
This is what “tell me what you want me to build and I’ll build it”. Disengaged teams and not stupid people are the ones who make funny meme-generating mistakes like that. And usually it’s these kinds of teams that smart developers are quitting.
Slide #25 - What about Scrum?
One last thing: I’m not advocating against agile practices or Scrum work-together like frameworks. In the delivery phase it makes a lot of sense to not get far ahead in terms of specifications and release and test fast. It’s this back n’ forth between discovery and delivery that is expensive.
Slide #26 - Innovation Benefit
Now, I wanna talk about innovation a bit. Innovation comes by differentiating enough from your competitors to offer something that is better or cheaper and, maybe this doesn’t come as a surprise to you, but it’s almost never because you are building a product right, but it’s because you’re building the right product.
Slide #27 - About competition
We see this in every kind of consumer products, like the iphone and all the smartphones that followed after it. See how they all copy the disruptor by doing the same things but choosing a random attribute to get “better”, like “more memory”, “better camera”, “bigger screen”?
Slide #28 - About competition
And I’m not throwing shade at these products. If you have tried any of them, like windows laptops, you know that they are amazing products. They work well, they are fast, strong, greatly build, with keyboards that don’t fall apart ;).
Slide #29 - About competition
The point is that these disruptors asked the right questions, such as:
“How do I make the user interface intuitive?”
“How do I make this machine more durable?”
“How do I make this car oil-independent while safer and faster?”
They asked the questions that their users were asking not the ones they could answer internally ("what do our users need?" vs "what can we build?").
Slide #30 - How?
And the place where you ask these questions is here. It is very important and hard to find the right problem to solve but you only do that by talking to people and trying to be as unbiased as possible.
Slide #31 - How?
Here it is too late. If you start challenging the problem you are solving or if you come up with a idea that would solve another problem, it is too late to find it here. It’s not impossible to shift course, but it’s gonna be expensive.
Slide #32 - Changing course
Here’s another schematic about course-change. Let’s say that you want to land somewhere and this is where you will get by, not doing anything. But you want to land up there, because this is your company or product vision that you believe will help you sustain a business, create a new market, anything.
Slide #33 - Changing course
With a certain amount of effort you might be able to get there. If you change course early enough you will be able to achieve your desired impact
Slide #34 - Differentiate early
If you applied the same amount of effort late in the process, where for example you started to build a solution for your wrong problem, then you would really have to spend a lot of effort not to land in the wrong place.
Slide #35
This is very important and I want to drive this point home. We often focus a lot on tactical activities such as roadmaps, prioritization exercises, agile delivery activities...these are all important parts but there is also a reason why you see medium articles, linkedin statuses, talks and workshops around these activities: they are relatively easy to teach (maybe not to apply but that’s another story). The hard part is to find the right problem, to discover (to remember Cagan’s definition) a valuable product.
Slide #36 - If you don’t build the right product it doesn’t matter if you build it right.
Our responsibility as PMs is primarily the strategy of the product. If we lose sight of that or are stripped of this responsibility then we are really not offering the value that we could be offering to our organizations.