Technology

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

AUTODOC outlines its digital transformation and methodology for rapidly establishing product domains within 90 days, demonstrating the process through organizational restructuring, focus on customer-centricity, and leveraging agile practices for enhanced efficiency and market leadership.
View all posts

TLDR

This is a two-part story of how AUTODOC is dealing with the pains of its own success and ambition and how we are continuously adjusting our structure, processes, mindset, skillset and culture to further scale the business in a customer centric, innovative and sustainable way. By carrying out a digital transformation process, elevating the company to a product-led organisation and creating product domains, we are preparing our organisational, operational and technological structure for the next exciting stage of the company – becoming the leading platform for our industry. Based on our experience, this is how we can now build a new product domain in 90 days – and a free template for you to explore and use in your own organisation.

Organisational digital transformation

AUTODOC quickly achieved strong market share, customer base and revenue due to our competitive advantages on product price and availability. Our organisational, operational and technological structure allowed us to achieve those goals but was limiting our ability to do more, more quickly and more efficiently. 

For example, a top-down approach, the proliferation of areas and stakeholders, conflicting requests, bureaucracy, organisational silos, and legacy technology were creating long development cycles and long decision making processes, defocusing us from what gets more impact, increasing technical debt, etc.

 

Image 1 – example of an inadequate prioritisation and development logic

To tackle those challenges we are going through an organisational digital transformation. This is a holistic approach to continuously deploy tech at scale and to leverage new technology, culture and processes for changing how companies operate and deliver value, improving efficiency, competitiveness, and customer experience by, for example:

 

  • adopting state of the art technological and development frameworks like agile methodologies, new programming languages, new services architectures, etc;

  • optimising communication, decision-making and prioritisation processes and workflows, for example by adopting one unique and decentralised prioritisation process;

  • implementing a data-driven decision-making process and “data over opinions” approach, balancing the discussion between different stakeholders and levels inside the organisation;

  • focusing on customer journey and customer centric insights at all stages of product development;

  • adopting an agile and flexible culture, with a big focus on small development and feedback cycles, experimentation and validation, development and product team empowerment and ownership of the products being managed by them, etc [1][2].

Product-led organisation and domains

But what would AUTODOC be transformed into? How would we do it and how do we assess whether this is the right thing to do? After recognising the problem and assessing the current situation, we opted to work towards transforming into a product-led organisation. 

 

In this model, the strategic priority is on product development and innovation with a focus on providing user value and engagement by having a product roadmap and decision-making process that is decentralised and driven by data and customer feedback and therefore defined by the Product teams. These teams are empowered to make decisions to drive growth based on learning gained through experimentation, data collection and continuous improvement. This model contrasts with other models like customer-led or sales-led models, where the focus, priorities, roadmap and Product teams’ role are different [3].

 

Image 2 – concept of organisational digital transformation

 

This product-led organisation would be built around product domains [2]: fully autonomous cross-functional teams (Product, Engineering, Design, analysts, researchers, data scientists, etc) built around specific metrics, customer journey stages and technological knowledge that share responsibility with Business for everything in their scope. 

 

This means that Business sets business goals and KPIs and that Domain teams do whatever is needed to fulfil those goals. This also means that the team is fully accountable for finding solutions to problems and taking responsibility for the success and failure of their initiatives. This does not mean that there are no “top down” requests – they should be the exception to the norm and always dealt with by Domain teams and not by separate teams.

 

These teams are also fully capable of developing something from “a to z”: identifying the need, estimating the impact, validating the problem, developing designs, back-end, front-end, UI, UX, release, rollout and subsequent impact confirmation and feedback loop with users and stakeholders. Its size should be representative of its importance and should not rely too much on other parts of the business or technology.

We kicked off with two “proof of concept” domains to validate our assumptions that this model suits our organisation and brings value and scale. Those domains were:

 

  • “Basket” domain, focused on the basket and checkout stages of the user journey and on metrics such as checkout conversion rate, percentage of paid baskets, etc;

  • “AUTODOC Pro” domain, focused on B2B users and tweaking the user journey to their needs.

 

Needless to say, they were a success, showing significant improvement on time-to-market, direct revenue impact and technical scalability, and we are now working on at least additional 5 domains, built around the other steps of the user journey, specific key target user segments or KPIs we want to focus on. One example is the Search & Discovery domain, which considers everything in the consideration phase of the E-commerce user journey (selectors, catalogue, search, PLP, sorting, ranking, filters, PDP, recommendations, reviews, etc) and focused on metrics like conversion rate, add-to-basket, bounce rate, etc.

Image 3 – a simplified example of product domains built around user journey

How to architect a new product domain

 

Knowledge comes with practice, so we are now in a mature state of building domains. We can now quickly apply a framework that allows us to scope, budget and roadmap domains in a short period of time. This process aims to define an initial common understanding between all stakeholders: a foundation that brings them to the conversation in a focused and guided manner, in a short period of time and with clear outcomes. By “initial” I mean that it’s something that will and should change over time, according to the goals and outcomes defined in this first version.

 

In each version or iteration of the domain, we should define goals and expected outcomes and adjust based on that. Again, “data over opinion” is key to level up the discussion between different levels of maturity, roles and hierarchy. 

In this methodology, we cover an initial version of the following goals:

  1. Vision

    1. Vision, mission and goals

    2. KPI’s and our strategic bets

    3. Business impact and costs

  2. Products

    1. User needs and personas

    2. User journeys, pain points and opportunities

    3. Stakeholders mapping

    4. KPIs for each product

    5. Roadmap and transition plan

  3. Tech

    1. Current technical structure

    2. Future technical structure

  4. People

    1. Current team, roles and responsibilities

    2. New ideal team structure, roles and responsibilities

  5. Processes

    1. Communication framework

    2. New team dynamics

    3. Tools to follow process and track metrics

 

 

We also define clear timelines, no longer than 3 months, with clear milestones in each of the above goals. This calendar should change according to each previously defined session outcome but the deadline should not change, so you might need to adjust the outcomes, for example by making some assumptions. 

 

In order to keep this process effective and efficient, we opted for a small multidisciplinary team with enough seniority and knowledge of their own areas. For example a six-person team with representatives from Product, Engineering, Analytics, Product Ops, Service Design and Research. Then, for each session, according to the scope and the depth to which we want to go, we invite specific people only for that interaction, like a developer or a Legal or Finance representative. 

 

Working sessions should be short, focused and with clear outcomes. For example, we opted for two weekly sessions of two hours. Each session requires preparation or homework – this is usually some reading about the topic being discussed, the expected outcomes and some information that the team should bring to the discussion. 

 

Also, by the end of each session, the outcome might need some work from the session facilitator, so that it’s clear and presentable. After that, it is shared with relevant stakeholders, like participants and sponsors, so that we create short feedback loops and gather their feedback sooner rather than later. This way, we don’t wait for the end of the entire process to get their feedback.

 

The session structure is based on first understanding our current status (metrics, user flows, user personas…) as well as possible, then analysing the user journey, because it’s the backbone of our new team structure, and then we start building from there. We start from the metrics and impact and go upwards until we go to vision, mission and roadmap. This way we guarantee a user journey and impact focused strategy, based on data over opinions, instead of a vision driven approach coming from top management.

 

In part 2 of this story we will go deeper into each session and the challenges we faced. Finally, we will share a template for you to explore and adapt to your organisation’s reality.

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

References

[1] https://enterprisersproject.com/what-is-digital-transformation

[2] https://www.mckinsey.com/featured-insights/mckinsey-explainers/what-is-digital-transformation 

[3] https://www.productplan.com/glossary/product-led-organization/

, Technology

Related stories