Moving a team to Product Model practices
A workshop format supporting teams to identify where to start in their journey to a Product Model
Following the hot debate about whether product teams can change without strong buy-in from leadership and stakeholders or if they are just doomed, I created this first version of a workshop in the last couple of days. My experience is that there are always areas for improvement, but you need awareness of where to start.
This workshop template supports teams in identifying behaviors and tactics for transitioning to a state more aligned with the product model. The audience of this workshop is either a complete product team or a subset like the product trio (product manager, product designer, tech lead). You can also run this team by team as a product leader or coach.
While I’ve facilitated similar workshops and collaborated with teams in this manner, this specific workshop is untested. I'm eager to receive your insights on the format. If you're considering running this, I would love to hear about your experiences so that I can refine this format.
You can go ahead and check out the Miro Board or read on for a deeper explanation.
The workshop
The workshop is all about different product model tactics and product team behaviors. The content is rooted in Marty Cagan’s Transformed book, enabling you to dive deeper into the concepts, if needed, in his material.
The behaviors are grouped into five categories: Product Teams, Product Strategy, Product Discovery, Product Delivery, and Product Culture. Each category has between 7 and 11 different behaviors, totaling 43.
The heart of the workshop is to rank each behavior according to how well you are already aligning to it and how easy it would be for you to progress in adaption. To get a clear overview and find out where to start, the behaviors are mapped to a simple 2×2 matrix.
About the axes
The vertical axis describes how well you have adopted this tactic, from good to far away. The horizontal axis represents how easy it is to introduce change to this tactic.
Where to place each topic on this axis should be pretty straightforward. Even if you over- or under-estimate yourself on a topic, it is a good overview of where your team sees areas of improvement. This might also lead to healthy discussions if there is a discrepancy around the self-assessment.
The horizontal axis addresses an issue I often see with teams and is an ongoing topic in many discussions in the product scene. Common phrases in the spirit of “I’m not allowed to do this“, “My leadership just doesn’t get it“, and “I know what we should do, but we can’t change that“ are all over the place. However, having worked with many teams and speaking to many product leaders and stakeholders, there are usually always some things entirely or nearly completely in the power of the teams. Nobody will stop them, or they only need to communicate clearly a change to be allowed to try something.
You place every topic with the participants on the matrix.
Finding the topic to focus on
The sweet spot for actionable behavior change is where things are in the team's control (easy to change), and the team is halfway good with this. If a topic is already in the upper third, it will get more complicated to drastically improve due to the Pareto principle (aka 80/20 rule). If it is on the bottom end, improvements might not be visible, or what good means might be unknown. One of the main goals, especially at the beginning of this journey, is to show visible results. The team needs to build up trust and show agency for change. If they get recognized as one of the teams delivering better results, they will more easily get more freedom to develop further.
Everything on the left will need too much political power or changes in other parts of the organization to make any movement. Don’t get burned there.
Map all the stickies out in the matrix. If you find yourself discussing one topic too long, split it to clarify it, or park it and move on. Don’t try to make it super exact. Walk through the topics quickly to find suitable candidates. There is no perfect answer or the best topic to start with. Remember, the idea is to get started instead of being stuck and feeling powerless.
Choose one of the topics in the focus area where it feels right to start. This should be a short discussion. Start by choosing only one. You can always revisit the board if you have more capacity for change.
Shorten the mapping session
To shorten this step, the facilitator can also pre-choose some topics or sort out topics they know the team already excels in or are currently not on the table.
Make it actionable
The last part helps to clarify what to do and how to show results. The steps are:
The improvement topic
The sticky you chose from your matrix.
The Shepherd
Somebody needs to own this. That doesn’t mean this is the only person acting on it, but if nobody explicitly looks after the progress, it quickly gets forgotten. Choose someone who seems like a natural fit (responsibilities, capabilities, time, etc.) and is eager to work on this.
Doing
Describe very clearly what you are going to do. Don’t stay with ‘better‘ – be explicit about what specifics will be done differently. This is your first guess, and it might change over time.
Measurement
Define a leading indicator you want to see improve. The best case is if the broader organization also cares about this, so you can use this later on to communicate your results. However, ensure you see quick results on this indicator and can measure it easily.
Check-In
Define the frequency and format you want to check in on your progress. This can be part of existing team rituals and should ensure to stay committed.
Pivot or Cancel
Define thresholds or events when you should pivot your activity or cancel. This is to ensure you already anchor in the beginning that a different approach might be needed or something might be wrong with your first placement on the matrix.
Now it’s time to get started
Copy this Miro Board to run this workshop.
Example
Let’s look at an example to clarify how this can work. The topic of “We work with identified and defined problems to solve, and not with predefined solutions“ is probably one many teams struggle with.
Team A gets direction from leadership with features to deliver, which they can autonomously ship. They get some context about the customer and business needs for every feature but are not encouraged to explore multiple solutions. However, they are responsible for defining the details of the solution.
They could start writing down the proposed solution and the identified problems in a product brief, adding more detail to their understanding of the problem space, and doing a short re-briefing with leadership through this document. Over time, they might start to offer alternative approaches in their re-briefs. They still don’t get directed by problems, but I think you see how they could steer the conversation more into problems to solve away from the prescribed solutions.
Let’s look at an alternative: Team B is directed by requirement documents with detailed design specs. They are not directly involved in creating these documents. Another team creates them and hands them over. Team B doesn’t have a lot of context, and if they come back with too many questions, the requirements team gets annoyed. If they start talking about customer problems, they get puzzled faces, and the conversation is getting shut down.
If Team B starts to shift to work with problems to solve, they will most likely have difficulty showing progress. They would need to convince many people that they even need this information. Most likely, they could not translate problems into working solutions. They had never done something like that. And, of course, the biggest blocker is usually trust from their organization. The organization would need to have quite some faith in the team that they can do so much additional work (when they are already struggling to deliver on time with the right quality).
Both teams would map all stickies and choose one in the focus area. Let’s stay with Team A and say they want to transition to be directed with problems to solve. They take this sticky and move through their action definition:
Improve: We work with identified and defined problems to solve and not with predefined solutions.
Shepherd: The product manager is most likely responsible for this.
Doing: The team decides to rephrase the feature request they receive as a problem to solve. They start to write short briefs describing the feature and problem, call out the identified risks, and check back with their leader. If this works out well, they introduce several alternative solutions to the problem within this document.
Measurement: To ensure they do what they say, they strive to have this written document for 80% of requests, with the problem defined. They don’t go for 100% because they know sometimes a feature is too small or obvious that the overhead would be too much. A second (very soft) measure is that the conversations switch more to the problem space. They don’t know how to measure this yet, but they want to be alert.
Check-In: The team already conducts a weekly refinement, discussing upcoming work, so they incorporate this topic because it directly fits together.
Pivot/Cancel: If the re-brief with leadership doesn’t work out, they know they need to pivot. Another pivot point is if they get backlash when coming up with alternative solutions or digging too deep into the problem space. Both situations are probably not a reason to cancel but more a reason to adapt how they communicate.
Ready to run?
You can start by making a copy of this Miro Board.
As said before, this is a prototype. Please ask questions and tell me about your experience in the comments or by directly messaging me.
If you think this sounds interesting but don’t have time or someone to run it for you, I would be more than happy to run this for your team, currently with a huge discount!