Every Team Every Step Doing Their Thing

One definition of a successful business is “an organization following repeatable processes leading to reliably positive outcomes”. In tech companies, the product function is arguably the most important part of the organization. The processes it follows to develop new products and features determine how reliable and how positive the outcomes can be. In skilled knowledge work, creating processes is a fine play balancing multiple aspects — providing clarity while leaving room for creativity, ensuring accountability while promoting collaboration, delivering to a plan while being able to respond to new learnings. Even within skilled knowledge work, building products occupies a special place due to the higher uncertainties involved — in the problems solved, the solutions developed and the reception of the solution by the market.

The default process — Each team doing only their one thing when their turn comes

Too often, as organizations become larger, left to itself, the product building process tends to go more towards the providing clarity, ensuring accountability and delivering to a plan side of the spectrum. This manifests itself as product managers being responsible for the roadmap and creating the requirements, then designers coming into the picture, then engineers and so forth. Essentially, this is each team doing their one thing when their turn comes — almost like an assembly line. But such a process is not suited for the uncertainties inherent in building software products and also does not fully leverage the knowledge and skills of each team. This results in some predictable challenges illustrated below.

Gaps between what’s possible vs what actually happens when the involvement of different teams in the product development process is limited to specific stages

Pushing the process towards Creativity, Collaboration and Learning

If we are trying to reduce the uncertainties that are inherent when always building something different than earlier and fully utilize the unique knowledge and skills of each team, a natural step is to think about what value can each team bring at each step. Let’s take roadmap creation as an example. Usually, product managers drive this step while working with product leaders and other functional leaders in the organization. While PMs need to definitely own this step, other folks can add a lot of value when involved actively.

• Engineers can suggest possibilities on what’s so far remained impossible problems to tackle but have now become technically feasible to take a crack. They also know which systems are technically fragile and need solidifying before they start showing up as problems.
• If they are part of the planning process. designers can help reimagine the fundamental user workflows apart from ensuring there is dedicated time for addressing design debt that keeps accumulating in any product as new stuff gets added.
• Testers can help PMs understand why the staging environment is always broken and why what should be a routine release often seems to need virtual war rooms stretching into the wee hours. Improvements to testability and tooling can then get into the discussion agenda.
• Analysts can keep PMs grounded by forcing rigor into the planning process and check if shiny new ideas actually retain their sheen after they are numerically scrutinized. They should also bring their asks related to reducing their repetitive work and ensuring clean data pipelines to the roadmap discussion.

Without the deeper involvement of these teams in the roadmapping / planning step, it is easy to imagine that the teams end up building sub-optimal ideas with good chances of getting disrupted and being forced to change plans midway.

Extending this discussion further, the illustration below (yes, it’s HUGE but wait till you get to the one further down!) lists what each team can contribute at each step. The overall idea is simple:

• Involve earlier — every team has a role to play at earlier stages by bringing to light problems that might otherwise get missed out and by helping generate more creative solutions.
• Involve later — every team has roles to play beyond the steps where they do their main work by ensuring what goes to customers truly meets the quality cut and is actually impactful.

Expectations from different teams at different stages in the product development process — leveraging each team’s knowledge and skill. Teams are required to participate earlier in the process contributing to higher exploration and anticipation as well as later in the process focusing on closing the loop and owning the outcome

How to operationalize this?

This all sounds great. But how can you take this from theory to practice? One way is to define the deliverables and what they should contain for each stage of a feature development process. The illustration below discusses this.

Deliverables for each stage of the product development process — with indication of parts that might not always be included, but should be insisted upon, to get each team involved at the stages where they can add value

In order to properly create these deliverables, each team will need to be involved. Teams can learn over time on the exact rigidity with which such guidelines need to be followed and how it can vary based on the type of feature being developed.

While the primary intent of the collaborative-and-deeper-involvement-of-all-roles approach is to build better products, there are side benefits that result in more engaged team due to:

• Higher ownership as a result of getting a voice in shaping the solution rather than being a recipient who does his part when he gets his turn.
• Higher outcome and impact orientation. Success or failure of what’s built starts to matter much more to everyone.

Ultimately, this empowerment of the team is the larger impact that can set up the product for longer term success.