Applying DesignOps to product teams

Enabling and streamlining product design’s best practices is one of DesignOps’ critical tasks. But to outline workflows that embed best practices, DesignOps practitioners need a consolidated understanding of product development and delivery methodologies, such as Lean Startup and Agile.

Patrizia Bertini
UX Collective

--

Design and Product teams have clear overlaps that need to be managed and optimised to maximise results.

As digital experiences and products grow and become more structured and complex, design and product teams need to review both their cross-functional and their internal ways of working to increase consistency, reduce inefficiencies and errors.

For this reason, today there is a growing focus on ways of working and operations: well-established processes can streamline complexity, turning best practices into actionable steps and seamless procedures that support the design teams to apply best practices into the daily ways of working.

As a transformative and transformational discipline, DesignOps focuses on enabling cross-functional collaboration through engagement models that ensure all steps in the product design process are being sequenced appropriately so that all parts involved can thrive and increase productivity, predictability, and quality of the outcome.
To achieve this, DesignOps practitioners need to master both the E2E design processes and the key product development and delivery methodologies.
Theoretical and practical expertise in these domains is critical to enable DesignOps practitioners to detail and outline cross-functional processes that embed best practices within the daily ways of working.

DesignOps is about operationalising best practices and embedding them into everyday’s workflows, to support both design teams and cross-functional partners to define product solutions that equally address user needs, business requirements, and technical feasibility.

Which best practices?

As both a strategic and a design function, DesignOps builds on all design’s best practices to define processes that enable the design teams to apply user-centricity at scale and to consolidate concepts and products that are viable from both a market and technical perspective and to maximise the business impact of design. By doing so, and by also applying a system thinking approach, DesignOps needs to work closely with all cross-functional partners and to be familiar with the critical frameworks and approaches that the partners apply, in order to be able to create consistent workflows and reliable engagement models.

Therefore the knowledge of all key approaches and frameworks, such as Design Thinking, Lean Startup, JTDB, Agile… becomes essential to assess, quantify, weight, and solve design teams’ operational inefficiencies through changes that have a direct impact on both the end-users and the designers.

Most designers apply Design Thinking in their work as a habit.
Yet, injecting Design Thinking into everyday workflows requires the definition of processes that integrates tools, best practices, templates, ceremonies, and engagement models that connect design processes with product managers’ and developers’ ways of working.

Because design and Design Thinking by themselves are not enough to realize and deliver experiences, a well-thought-through E2E product process needs to include critical approaches that support successful cross-functional development.
The most effective E2E product process is the one that streamlines all best practices and that supports all teams involved by enabling ideation, validation, and delivery best practices by applying key methods: Lean Startup and Agile.

A quick overview of the top 3 approaches

Design Thinking’s ultimate scope is to systematise problem-solving and to focus on a deep understanding of the users, their needs, and the opportunities. Design thinking is an iterative process to create innovative solutions to be tested (some resources here and here).

But designers also need to test the ideas and validate them, and this is where Lean Startup comes into play. Lean Startup is an approach whose goal is to speed up the product development cycle by verifying solutions and ideas through iterative hypothesis-driven experimentation. Designers apply Lean approaches and run experiments to test if the concepts are solid and accepted by both the users and the market. It is a critical step that works iteratively and in parallel with the Design Thinking approach, therefore tools and best practices need to be developed in ways that streamline and enable these two approaches to work in parallel.

The Lean Startup is a well-defined and documented approach (see here and here) and it generally is managed by both the design and product teams as both teams are responsible to validate the concepts and consolidating the final solution by combining user-centricity, technical feasibility, and business impact.

The final stage is when the prototypes and designs are handed over to the engineering for implementation — and this stage is where the focus is on executing the development to bring the ideas and concepts to the market.

And this is where Agile comes into play. Agile is an iterative approach to project management and software development whose aim is to produce shorter development cycles to release a version of the product more frequently (more here).

These three approaches are all necessary and critical to the delivery of successful products and experiences: if Design Thinking focuses on defining the needs and the requirements, Lean Startup will test the proposition through rapid experiments that can ensure the solution is viable and has a market. Agile literally builds on the validated propositions to bring the experiences in the hands of the users.

All three approaches happen in waves and with overlaps, for this reason, an understanding of each methodology is critical to ensure goals and ownership are clearly set and processes are optimised to enable all three approaches to happen at the right time.

[For a more detailed explanation of how these approaches work iteratively and how they are integrated into the process, please refer to this article by Raj Nagappan]

Best practices in practice: who owns the process?

While it should be clear how these approaches are all needed to deliver user experiences and products, it is not always obvious who is responsible and who owns the implementation of these approaches across the design and development workflow.
It is the individual contributors’ role to set up the right approaches? Or the design managers? Or the product managers?

If we look at the Design process from idea generation to delivery, we can see how the three approaches have specific focuses that address specific business questions, making these three approaches inter-dependent and critical:

A linear visualisation of where the Design teams focus within the E2E design process. This image also shows the product teams’ focus to highlight how complementary these teams are and how their focus overlap partially when it comes to validating the proposition.
A linear visualisation of the design teams’ focus within the E2E product design process. This image also shows the product teams’ overarching role: product and design teams are complementary and both critical to ensuring the proposition is validated — although there are apparent overlaps, defining clear ownership is critical to ensure the final product delivers on all expectations: user, business, and technical.

The role and responsibility of the design team are concentrated at the beginning of the process when the key question is to understand the users, the opportunities, and the requirements. Design’s learnings and output need then to be verified and they need to be tested with the users— this is the phase when design and Product Managers (PMs) collaborate, to ensure there is a full alignment between the user needs and the business goals.

The visualisation is linear and not adherent to the real workflow (for a more detailed explanation see here), but the ideation and validation phases happen simultaneously generating loops where the learnings from the experiments inform the ideation phase until the proposition is clearly defined.
This is why while designers focus on the opportunity space and consolidating the solutions, the product focuses on refining the solutions through hypothesis-driven experiments and aligning business and technical requirements.

And these two aspects are strinctly interconnected and they need to constantly move together: generating business value only happens when the experiences delivered to the users meet their needs and exceed their expectations.

And here comes DesignOps

DesignOps come into play to support the design teams by owning best practices to make sure they are applied in the most effective way, minimising the effort required to apply Design Thinking and Lean approaches.

If we expect designers to apply Design Thinking and Lean Startup approaches consistently, it is DesignOps’ responsibility to make best practices part of the ordinary workflow and to develop cross-functional engagement models that facilitate collaboration and business impact.

This is why a DesignOps practitioner needs to fully understand and appreciate how Design Thinking, Lean Startup, and Agile interact on a practical level and what is their specific contribution within the product and design lifecycle.

DesignOps, as the name suggests, focuses on the design phase, but to ensure the outputs from the design cycle move across the product cycle without risks, it is important that DesignOps also contributes and aligns with product and engineering teams. If DesginOps drives the processes and outcomes of the discovery and ideation phase, it also contributes to the consolidation of the concepts, until there is a clear handover to the development team.

DesignOps owns and supports predominantly the discovery and proposition validation phases, making sure there is an enabling infrastructure that allows Design Thinking and Lean to deliver a consolidated concept ready to be handed over to the developers’ team.
DesignOps owns mainly the discovery and proposition validation phases, making sure there is an enabling infrastructure that allows Design Thinking and Lean Startup to be executed and to deliver a consolidated concept ready to be handed over to the developers’ team.

It is therefore important for anyone moving into the DesignOps space to familiarise themselves and to be fluent in all product development approaches: knowing which are the techniques, tools, and methods is an essential part to develop design processes that deliver impact and business value.

The lack of understanding, from both a practical and theoretical point of view of these domains, limits DesignOps’ capacity to work at a strategic level and keeps the function closer to a programme management role.

DesignOps’ limits

Design Operations’ boundaries are in the name: it is not DesignOps’ remit to manage the entire E2E delivery process.
DesignOps has a clear focus on ensuring design best practices are executed through a series of different approaches, including tools, playbooks, best practices, templates, and ceremonies.
DesignOps focus in on the initial phases, where design has the biggest impact: the definition of the problem, the ideation, and the validation of the concept.

Simply put, DesignOps owns the implementation and execution of Design Thinking and Lean Startup approaches to ensure the experiences are consolidated and they are handed over seamlessly to the development team.

If Design Thinking falls primarily within Design and it is DesignOps’ responsibility, when it comes to implementing Lean Startup approaches, the responsibility may be shared between Product Managers and DesignOps practitioners. The concepts’ validation and the hypothesis-driven approaches require design and product teams to collaborate to build the hypothesis and to equally include the users’ perspectives and the business and technical feasibility aspects.

As digital products and experiences are becoming more complex and teams grow, orchestrating the E2E process across different teams (Design, Product, Engineering) may become cumbersome.
This is the reason why to ensure that the product vision and strategy are embedded consistently, DesignOps has found a new partner, ProductOps.

ProductOps is someone that enables product teams through streamlined processes to deliver the product roadmap through an intense focus on prioritisation and planning to maintain consistency within the product experience.

ProductOps takes from the concepts and initial solutions developed by the Design teams and supports product organisations to move the idea forward and take it to the delivery stage.
ProductOps takes from the concepts and initial solutions developed by the design teams and supports product organisations to move the idea forward and take it to the delivery stage.

Although some DesignOps practices have started creating internal ProdcutOps roles within DesignOps (R. Posner wrote this in 2020) there is a trend of ProdcutOps being part of the product organisation.

Unlike product managers who operate on a single product line level, a ProductOps practitioner works across multiple products supporting and defining how cross-functional product teams should be working and ensuring the product vision is implemented consistently.

In a few words, Product Operations is a cross-functional role designed to guarantee a successful collaborative work among all teams connected to the product life cycle e.g. the people who are building the product — product managers, project managers, R&D, and engineering — as well go-to-market roles like product marketing managers, sales and customer support. (P. Becchetti)

If we accept this definition, it becomes evident how experimentation is a shared responsibility as hypothesis-driven experimentation is critical to ensure a balance between the user needs and the innovation opportunities are delivered effectively.

So if DesignOps focuses mostly on ensuring designers have a clear path to innovation and user-centred design, the validation of the solution is a shared effort between the two functions.
Both functions operate at the same altitude and both work to maximise teams’ impact. Although the focus may be different ProductOps and DesognOps are complementary and share some similarities (more here and here).

Since ProductOps is responsible for the product roadmap and implementation, it is closer and more focused on the delivery aspect and can influence and be variously involved with the Agile teams.

In its role, ProdcutOps can influence the engineering and development effort and it can collaborate more with delivery managers to ensure that all workflows are aligned and optimised to deliver according to the product roadmap and strategic priorities.

What’s next

Given the critical role DesignOps has in setting the E2E product workflows and the need to establish solid engagement models, it is DesignOps’ responsibility to know and own these approaches and implement the methods through a well thought through a collaborative approach with the core partners: the designers, the PMs, and the ProductOps partner.
Accepting and developing this partnership is today a key aspect to ensure organisations deliver valuable products and implement best-in-class approaches by design.

Note: The development stage is out of scope and not part of this article.

--

--

Inquisitive mind | interest: DesignOps | Innovation | Digital transformation |Co-Creation | Privacy | Experience economy | Creativity | System Thinking