Part 2: How to design your Ways of Working for software product teams

In part 1 we went through why you need to think carefully about your Ways of Working in your software product teams and we also covered who you are designing for (the Product Trio) and their different responsibilities.

With this understanding we are now ready to dive into how your Ways of Working can look like and what it must contain to effectively propel your teams forward while tackling the 4 risks of product development that I talked about in part 1.

Why process matters

I love processes but I also appreciate that not everyone feels this way. The reason why I love processes is because it allows you to define a common reference that can be used for continuous improvements. As you start using your process you will learn from it and use those learnings to refine your process. This provides a setup to anchor your learnings in a common framework that over time will reflect your collective best practice for how to execute a given process efficiently and effectively.

In product development, your Ways of Working will over time contain your companies best practice for how to build software. It will provide guidance for your teams on what to consider when solving problems for your company and customers.

One of the common arguments I hear from people who generally don't like to follow a process is that it becomes too heavy/rigid, time consuming and introduces unnecessary overhead for the team. IMO this is a common misconception and teams need to adapt the process to fit the size and complexity of the problems being solved. If you are tackling big problems with big risk then it take more time to move through the process. If you tackle a smaller problem with less risk then you can accelerate and literally cover the entire process in hours or days. In short, adapt to the given situation that you are in.

A Ways of Working template

Your Ways of Working defines how to tackle a problem and create an outcome. It helps your team work from discovery towards delivery in a consistent way.

The Ways of Working model I will go through in this article doesn't cover the delivery/development work by the engineers. I will though explain the 'Handover to Engineering' and the expectations towards the engineering team going into development of the feature.

I'm also not covering how to prioritize which problems to tackle, but you can check out my product talk on the topic about aligning your company around the most important strategic objectives.

Lastly, the model I present is a simple view and if you are managing multiple teams you also need to manage cross team dependencies.

The Ways of Working cover five key sessions that typically materialize in a set of meetings, but for simple problems and features they could also materialize in asynchronous communication e.g. in a dedicated Slack channel.

Feature Kick-Off and Problem Alignment

The Feature Kick-Off is one of my favorite events and probably the most important one as it frames the problem and solution space and outlines the direction the team must pursue. As the name imply, this is where you kick-off the feature you want to work on by aligning the team around the problem you are tackling.

One guiding principle for the Kick-Off is that you should be talking very little about possible solutions and a lot about the problem. The value and viability risk is really what you are framing here by stating why this problem is significant and for who. Introduce domain specific context and emphasize any considerations relating to your sales, marketing, finance, legal etc. functions, that might impose constraints for the product team.

An integral part of the Feature Kick-Off is the Feature Brief also called the Design Brief in some companies. The Feature Brief is a document that zoom in on the problem to solve and the goals that the team can use as a reference to measure their solution against.

What information to include in your Feature Brief depends on your company, your industry and your teams. I have included a generic template below that you can expand from:

Once the kick-off is complete and the Product Trio or team has the necessary understanding of the problem, the context and the goals to be achieved, then the designer will take the lead on shaping the first parts of a solution. Some solutions don't have a user interface, but will still require the engineers to design the API's, data models and other technical parts of the solution.

If you are managing multiple product teams it is important to identify potential cross team dependencies as part of your kick-off session. At this point, you might already know that you will need involvement from your platform team or another team owning an interrelated part of the customer journey. Make sure to plan for cross-team alignment to discuss dependencies, planning and prioritization. I'm planning to write an article on Team Composition and Typology and how to design your product team structure to reduce dependencies.

Design Critique (Jam)

Design critiques are used to align the solution approach and can be more or less formal. I also like to call design critiques for 'Jams', where the Product Trio are jamming on different challenges to align on approaches and ideas. Critiques or Jams can happen within the design team focusing more on various design elements or involving the engineers for rapid feedback on feasibility.

In my experience more junior designers often misunderstand critiques and jams and feel they need to have mature thoughts before seeking feedback. This is not the case and getting fast feedback on solution approaches are often the most effective way to shape and design a feasible solution. Asynchronous critiques also work well for some types of feedback. Just be clear on what you want feedback on so it doesn't go off in a direction.

During this phase the team should also discuss if they need to run experiments to test hypothesis and collect data on value, usability and feasibility.

Feature Review

Feature Reviews are typically more formal review sessions involving the Product Trio and potentially members from other product teams as well. The review session is a decision making meeting where the Trio makes trade-off decisions weighing alternative approaches to solving the problem. In part 1 of this article, I wrote more about the trade-offs, so I'll skip that part here, but one thing that will emphasize with capital letters is to always agree on what is needed to get to the final design.

Product Teams consists of people who are passionate about building things so remember the inherent risk of getting caught up in scope creep because the team want to do more.

This is where the Feature Brief is key as it must clearly define the problem and expected value to keep a laser sharp focus within the team. It is natural that the team will identify areas of uncertainty that requires further exploration to be understood and it is absolutely fine to move forward despite having areas that are not fully understood. If it is possible to revert downstream and address it through an experiment, beta-testing or something else then it is a calculate risk evaluated against the opportunity cost of not moving forward.

At the end of a review meeting, ask what is needed to move to the next stage so you keep momentum and propel the team forward.

Design Demo

The design demo is intended to gather the most important stakeholders from outside the product team to demonstrate the designed solution and how the product team propose to solve the problem. This meeting is not mandatory but is a great way of getting buy-in from important stakeholders. During the session the Product Trio will gather feedback from the stakeholders and it is then up to the Trio to decide if they need to refine the designs before starting development or if they will keep the feedback for later iterations.

Handover to Engineering

Once the solution is designed it is time to start development. In many companies there are some critical misconceptions about how to drive the development forward and who are responsible. Some teams have product owners, SCRUM masters, business analysts and I don't know what to babysit the engineers and make sure they know what to do. I can't overstate how wrong this is! A strong empowered engineer is by far the most equipped person to structure and plan the development work.

A guiding principle in the handover, is that the engineers take the responsibility for transforming the product and design specifications into high quality software. Prioritization and refinement was done as a collaborative effort in the Trio and is reflected in the product and design specifications. The engineers will then breakdown the features and user stories in meaningful tasks and plan and coordinate the continuous deployment within the engineering team. Product and Design will be involved as the solution is taking form and provide feedback on interaction patterns, navigation, information architecture or other white-spots that might not be fully covered in the specs. This is a natural part of the Product Trio's dynamic where close collaboration, feedback and discussion are a natural part of the team dynamics.

I know this might seem like a major cultural transformation from how your teams work today and I'm not saying it is an easy change. But making sure you empower your engineers to take full responsibility is one of the most critical things to have a high performing product organization.

I hope you enjoyed this piece! Stay hungry