Technology

How to build a product domain in 90 days – part 2

In part 1 of this story, we contextualised our domain building process and explained why we were carrying out this transformation. In this part 2, our goal is to go deeper into each part of the process and give you a free template for you to explore and adjust to your own organisation. Let’s look in detail at each working session.

View all posts

Session 1 – Methodology and “as is”

It’s important to set the correct scope and expectations from the beginning. It’s also key to understand where we are if we want to effectively understand where we want to go and how to get there. So this first session is divided into two parts. The first part is focused on precisely part 1 of this article (that you can check here), where we explain why we are doing it and key concepts like digital transformation, product-led Organisations and product domains.

The second part is focused on going through all the available information about the products in questions: metrics, funnels, user insights, backlog, key developments, etc. If those products are already managed by product managers, we bring them to do a quick, structured presentation and Q&A session, with a specific format shared in advance.

By the end of the session, you should be able to fill a table with all information available for each product and the existing gaps. Those can be tackled during each session preparation or postponed to when the domain starts, according to its importance to the domain definition. Don’t forget to share the outcome with the stakeholders.

As homework, ask the working group representatives to gather and structure all existing data around user journey and funnels, because it will be the foundation for the next session. They can also read more about user journey mapping [1] [2]

Image 1 – an overview of an example of Miro board for one of our domain working sessions

Session 2 – User journey mapping

Product-led organisations focus on the user, the journey and the needs, so our work should be guided by a solid foundation based on user journey mapping. It should be possible to link everything we do to this mapping and to each stage, user action, touchpoint, etc. Ultimately, the business goals, roadmap and structure should reflect this.

Additionally, we should map the most important funnels specially, because we have different user segments, origins of traffic, demographics, applications and websites, etc. Only by better understanding this can we understand the importance for each step and how we should organise ourselves based on that importance or potential. Please don’t forget to share the outcome with stakeholders.

As homework, the group should read more about existing methods for building strategies, what are lag and lead indicators, OKR, stakeholders, etc, and bring all available data about these topics. [3] [4] [5]

Session 3 – Vision, KPI’s and stakeholders

Now that we know where we are (Session 1) and that we know main users, flows, needs, pains, metrics, etc (session 2), it’s time to start thinking about where we want to go. By the end of this session we should have a strategic canvas.

Please note, that this is an initial version, based on whatever information and discussions you might already have and based on everyone’s vision. It should change according to the remaining sessions and stakeholders feedback. You will revisit this canvas every time you finish the remaining sessions.

To set our vision and goals, we will start “bottom up”: we start with metrics and we end up on the vision and mission, allowing us to set something grounded in business impact and user needs – instead of the other way round (top down and “vision driven”). We list them, understand how they connect with each other and which ones are lead and lag indicators, we identify clusters and finally we identify which ones we can/want to tackle. Finally we set goals based on organisational priorities, our commitments, benchmarks, you name it.

Stakeholder mapping is essential to understand if any scope should be added based on a major dependency or interest from a stakeholder (domains should be as independent as possible). It’s also important to set the communication plan – how to set expectations, communicate the roadmap, get feedback, etc. Here the exercise is similar: we map, categorise and prioritise them, based on interest and power. Finally, we identify threats that might come from stakeholders, like resistance, conflict or competition.

Again, share with stakeholders and as preparation for the next session invite attendees to get info on current and future technical architecture (even if just ideas or intentions).

Session 4 – Technical architecture

This session will be more technical and will be helpful in understanding if the vision, goals and metrics aligned in the previous session are viable or not, and what’s technically needed to make them work. It will also be relevant to identify dependencies and evaluate if they should be brought into the domain – domains should be as independent as possible. Finally, this is key to understanding the number and type of teams and roadmap.

For this session, you might want to invite people with deep technical and operational knowledge, like a developer.

Now, let’s go back to the previous session outcome and cross check if it still makes sense, or if any unavoidable technical constraint was introduced. We might need to adjust it, or guarantee we can solve it, or ask for stakeholders’ help.

As always, share with stakeholders and distribute homework: gather current teams, roles, responsibilities and interactions. In terms of reading, it’s important to be familiar with concepts of the RACI Matrix [7].

Session 5 – Team structure

By this session we already know where we are (sessions 1 and 2) and where we want to go (sessions 3 and 4). We should now focus on understanding how to get there – structure (session 5) and roadmap (session 6).

We kick off the session, we focus on discussing current team structure, responsibilities, processes and tools, by filling in two matrices. Then we do the same exercise for the ideal structure. Finally we discuss team values and the principles we want our teams to be built around.

We then jump to prioritising the team building order: it might make sense to start from one part or with an interim version, depending on existing resources, priorities aligned on previous sessions and technical constraints or opportunities. We can revisit this later on, when we align on the roadmap priorities.

This time it’s important to share not only with stakeholders you were previously communicating with but also (if applicable) with the existing teams, so that they can also be part of their future definition.

Share this with stakeholders and, as homework, the team should be prepared with information around current communication flow to and from the previously identified stakeholders (session 3) and roles (session 4) and read about the methodology we will use next session [8].

Session 6 – Communication

Now that we know where we are (sessions 1 and 2), where we want to go and our stakeholders (sessions 2 to 4) and the ideal structure for that (session 5), we have to understand what team dynamics and communication tools and skills need to be put in place to guarantee that this structure reaches the goals.

We start by mapping the current communication flows (to, from, goals and channels) and identify improvements. For the ideal communication flow, we start with some key principles we want to implement (like resolve conflicts quickly, promote bottom-up communication, etc). Then we use the “current communication flows” exercise and we prioritise them according to their urgency.

Finally, let’s find the optimal communication channels recommended in the bottom layer. More intrusive channels have high-impact formats that deliver immediate widespread attention. Less intrusive channels use subtle formats that achieve sustained behavioural change. Here we should map everything from tools for updating stakeholders, tools for fostering internal communication, and tools for tracking development progress, where we should create support documentation

Don’t forget to share with stakeholders. Before the next session, the group should gather all existing initiatives, requests and ideas currently in development and in the backlog for the products being considered. They should also do some reading on principles for prioritisation and roadmapping. [9] [10] [11] [12]

Session 7 – Roadmap and business case or P&L

Now that we have vision, metrics, technical and team structure and communication channels, we need to align on our deliverables and how much archiving this will cost.

First we list all initiatives, requests and ideas. Please note that in this methodology there are no “technical” or “product” initiatives. All initiatives are evaluated through the same prism: do they answer our chosen goals and impact or metrics, and how.

Then, we discuss if they are “jigsaw puzzles” or “quests” and then we select “quick wins” and “low hanging fruit” we can start from [9]. Next, we prioritise the “must-haves” or “wows” from the user perspective [12]. We can now define a “now, next, later” roadmap, clearly showing where we want to start from. More than the dates, the important thing is to set the priorities and the order right. It’s also important to understand this is a continuous roadmap that should be revised as often as possible based on the most accurate information, for example every quarter.

Next, do the adjustments needed in the team structure and building priorities defined in session 5 or the other way round by adjusting the roadmap based on those structural constraints.

Finally, calculate the costs of this structure and the expected impact coming from your goals or prioritised initiatives.

Share with stakeholders. This is typically where they start seeing how all the pieces come together and might increase the amount of feedback and questions. Accept or refute based on data over opinions and each stakeholder’s power and interest.

Free template!

And here you have it! This is a simplified version of the exercise we do. Feel free to use it and adjust it to your organisation needs. This came together based on our experience, trustful existing models and interesting opinions from other product leaders and companies. We did precisely that, we picked up pieces from different places and came together with our own process.

Playground – Search and Discovery New Domain Template

Now it’s your turn! And don’t forget to give us feedback!

Author: Pedro Leão Santos, Group Product Manager and Domain Leader for Search & Discover Domain