Setting up Product Development Processes

How product leaders can help their organization effectively execute

One of the essential areas of responsibility for product leaders is setting up the processes of the product development department. For an overview, read my high-level article on product leadership responsibilities, or continue reading for a deep dive on processes that are relevant to the product organization.

To set up any organization, you need to put in place an organization structure as well as processes. A product development organization is no different: once the org structure is in place, you also need to establish the right processes.

The processes in a product development organization can be thought of as having three layers:

The inner layer are the core discovery and delivery processes that typically happen within the scope of an individual product team. The second layer are processes that align the entire product organization. They include direction and goal setting, resource allocation, as well as feedback and guidance. The outer layer are processes that span to other teams outside of the product development organization, for example to coordinate with marketing, sales, or support.

Discovery and delivery processes

Discovery and delivery processes are at the heart of the product development workflow. These are the processes that the cross-functional product teams will spend the majority of their time in.

A key balance to strike for these processes is how much should be standardized across teams and how much teams should be able to shape their own processes. Standardized processes can make it easier for people to move from team to team and can also increase transparency and ease of coordination between teams. Self-organization, on the other hand, can increase both the motivation and the productivity of individual teams.

Clearly, one important factor then is how stable the product teams are. If teams are being spun up or re-shuffled every few weeks, you need more standardization since otherwise every adjustment requires re-negotiation of processes. For longer-lived teams, a higher degree of self-organization makes sense, since teams can optimize their workflows over time.

It is useful to think about these processes along a number of different dimensions:

• Steps / activities: what are the different activities that get done over the course of the development workflow? What are dependencies between the activities? What are normal and exceptional paths?
• Roles & responsibilities: what roles are involved in the various activities, and what responsibilities are associated with them? Who is involved in which activity in what way?
• Interactions / forums: What regular meetings or other check-ins occur along the process? This could include anything from daily standups over planning and retrospective meetings through to formal reviews and approvals.
• Artifacts: what formal outputs (other than the finished software) do the process steps have? This can include things like briefs / one-pagers, product requirement documents (PRDs), development tickets, A/B test result reports, etc.
• Tools: what tools are used to support the process? This could include things like ticketing systems, source control systems, design tools, data analytics tools, knowledge repositories, etc.

From the above list, it’s immediately clear that you could put up a very rigid process corset with strict requirements for each of these dimensions. As mentioned above, that would run counter to the idea of self-organized teams. For each of the dimensions, a good consideration is what the minimum standard to set would be to allow the broader organization to function without impeding team effectiveness.

Areas in which standardization across teams makes sense are any discovery and development process steps which directly interface with other teams. Some examples of this are:

• Customer outreach and research: touchpoints with customers need to be coordinated across different teams. Otherwise, it can be very confusing and a bad experience for customers if multiple teams reach out to them in different ways without knowledge of other interactions. This would reflect negatively on the company and product and therefore needs to be avoided.
• Product, design, and technical review and feedback: there should be opportunities in the discovery and development process for teams to get feedback and guidance on their work in progress from both leadership and peers. These review and feedback sessions help align the product development organization in terms of what is on the product roadmap and improve the product by soliciting feedback about product, design, and technical decisions. They are also a critical opportunity for leaders to understand the work and performance of their teams and identify coaching and growth opportunities.
• Ticketing / task management: this is a bit of a tricky one. In general, since managing tasks is such an essential part of organizing one’s work, it makes sense for every team to be able to use their own methods. If one team manages their work in Jira and another on sticky notes on a wall, so be it. However, allowing every team this autonomy means that as dependencies between teams occur, it becomes more and more difficult to keep up with the status of the work. If individual tasks regularly require contributions from other teams, it is therefore beneficial to have a certain degree of standardization.
• Code versioning and integration: this one is pretty obvious: code that ends up in one codebase should be managed together. There might be parts of the toolchain that differ — for example, for backend and frontend code, or depending on the programming language — but it should all be part of one big, standardized workflow in order to be able to manage dependencies.
• New feature launch: how new features are launched and communicated to customers (or not) should ideally be consistent across teams. Otherwise, the situation can get very confusing for users if some changes are announced, some have in-product communication, and others simply appear. This is not to say that there needs to be a cumbersome launch process — the common line might be to launch quickly without communication — but that it makes sense that all teams follow the same approach.
• Documentation of research, concepts, and A/B test results: once a company starts getting out of the “five people in a room” phase, it starts having a history. This is especially the case once the first people start leaving the company — over time, not for all decisions that were taken in the past there is still someone around who can explain them. There are two big risks that follow from that. The first one is that people start doing things “the way we’ve always done them” without understanding what the reasons are, and therefore not finding ways to improve. The other risk is wasting time trying something that has failed in the past due to unawareness of past activities. To avoid these risks, there should be a common process to document key insights and decisions for future use.

One other aspect to consider standardizing is the capacity and processes for ad-hoc work. It is sometimes alluring to set up a seemingly perfect process for setting goals, identifying opportunities, discovering solutions and delivering them, only to then be derailed by an onslaught of small ad-hoc tasks. This has the risk of making product teams completely lose focus. In these cases, it might be better to specify a capacity for ad-hoc work (e.g., 80% work focused on the team’s main goal, 20% ad-hoc) along with rigorous prioritization of the ad-hoc work to identify the most critical tasks.

Processes spanning the entire product organization

The second layer of processes that should be set up and standardized are processes that span the entire product organization, not just a single team. These processes don’t necessarily need to be super formalized, but product leaders should be mindful about them.

I’ve written extensively about some of them in the past, so instead of diving to deeply here, go read the full articles for more information on what I consider best practice. There should be processes in place for the following:

• Strategy and direction setting: establishing and regularly revising the product direction, and aligning work of the product teams against it.
• Product roadmap: developing product improvement themes, putting them on a time horizon, and then delivering product changes against it.
• Resourcing and team setup: setting up individual product teams and allocating people to them in order to deliver on product goals.
• Performance and development management: establishing expectations and growth plans, providing feedback, and helping the team grow.

Cross-team processes

The last layer addresses processes that involve parts of the broader organization outside of product development, like marketing, sales, customer support etc. What processes exactly will need to be defined here depend a lot on the overall organization and broader environment, for example, whether the product is a B2B or B2C one. Without getting overly specific, here are some archetypical processes that need to be considered.

The first archetypical process is the alignment of goals. In a great organization, the whole company has a goal hierarchy in which team goals, department goals, and company goals are connected. This, of course, ties in with the process to set the product direction and roadmap. Product goals should be set and regularly revised in lockstep with company-wide goals, and if there is no company-wide goal setting process, then product leaders should drive alignment across the company on the product goals at least. Conversely, product leaders should be aware of goals of other departments, like sales and marketing, and if there are mismatches in priorities, a round of alignment and re-prioritization is in order.

What can make this alignment process particularly tricky is the fact that with empowered product teams, theme-based roadmaps, and iterative discovery, product teams will have only a vague idea what changes to the product will actually ship. Especially marketing and sales teams will often have a more deadline- and delivery-based approach to goal setting and planning, and it will require a lot of coordination and cultural adjustment to ensure you land on a system of goals that works for all sides.

Another important archetypical process to consider is involving stakeholders outside of the product development organization in ideation and discovery. Fundamentally, there are two different mechanisms to this process: push and pull. The “push” mechanism means that a stakeholder pushes potential product chances to the product organization, for example, in the form of feature requests and bug reports. The “pull” mechanism means that the product team actively solicits ideas and contributions from stakeholders, for example in the early stages of the discovery process. In general, both of these mechanisms are required, but the pull mechanism is vastly preferable. Pulling stakeholder contributions allows making them specific to the current strategic focus areas, whereas pushed contributions tend to be more “random” and have the risk of scattering the focus of the team.

It is worth noting that frequent “pulling” is more likely to give the stakeholders the feeling that their voices are being taken into account in product development and therefore might reduce the amount of “pushing”. Nevertheless, processes for both need to be established, and for any pushed contributions that are prioritized to be implemented, capacity needs to be carved out.

One more note about collecting “pushed” feedback like ideas, feature requests, and bug reports. It is common practice for product teams to put all of them into an ever-growing product backlog, and perhaps even communicate that to the stakeholder. Personally, I don’t believe in this approach. It only leads to an enormous backlog that becomes unwieldy and impossible to manage. In addition, it’s not like a product team ever runs out of things to do and needs to check the backlog of pushed ideas to just find anything to do. Therefore, I suggest the following approach:

• Triage: any input that is pushed gets reviewed and prioritized on a regular basis (e.g., weekly). This is most important for bugs, but can also be applied to feature requests and other ideas. In the triage process, input is prioritized by how critical it is (for bugs and sales-blocking feature requests) and how well it fits with current strategic priorities. (There should of course be a fast track process for critical issues affecting production, but it almost goes without saying that you don’t wait a week to triage the issue if your app isn’t working right now).
• Forward ideas in focus to product team: any ideas and feature requests that match the current strategic priorities are forwarded to the product team working on the respective area. According to the principles of empowered product teams, the team then autonomously decides whether the idea should be pursued or not and/or involves the stakeholder whose idea it was in their discovery process.
• Idea collection on theme level: for any ideas or feature requests that don’t fit with the current strategic priorities, but fit with themes slotted on the roadmap for a later time horizon can be collected at a very high level in a document for that theme. This will help with ideation and scoping of the theme once it is being worked on. It is important to understand that this doesn’t mandate that this idea will be worked on in the context of the roadmap theme, it is simply one piece of input. The stakeholder who has brought forward the idea should be documented along with the idea, so that they can be involved in discovery once the time comes.
• Close non-prioritized items: I believe that any item that after this process hasn’t resulted on something that will be built in the near future (say, in the next six weeks), should be relentlessly closed. This avoids creating a backlog that becomes unmanageable. Ideas are dime a dozen, and the good ones will keep coming up again and again anyway, so there’s no need to create a permanent record of the ideas someone had in the past. It is also far fairer and more transparent to tell the originator of an idea “thanks for your input, but your idea doesn’t fit with our strategic priorities right now, and you are welcome to bring the idea up again when our priorities have evolved” (or “and we will ask for your input once we start working on area X”, just make sure that actually happens) than telling them “we have put your idea on our backlog and might work on it at some point”.

An additional archetypical process that has push and pull mechanisms is feedback on work in progress and new features. Here, again, it is preferable to pull some feedback by “dogfooding” future product changes (meaning to roll out future versions of the product internally before launching them to the public), or by providing stakeholders formal opportunities to provide feedback on features that are currently in design and development. It is important for this feedback loop to not become an “approval” loop though, otherwise you risk designing the product by committee, which is generally a recipe for bad products. Product leadership has an important role to play to make sure that stakeholder voices are heard but that the product team in the end can make their own decisions based on all the input that is available.

As mentioned above, the fact that processes for all three of these layers need to be in place doesn’t meant that there has to be a huge process bureaucracy with long guidelines, checklists, and RACI charts. The fact of the matter is, you have processes, regardless of whether you write them down. Processes are simply what people in the organization do to get things done.

Even if you despise formalization and fear ossification that can come from too much process bureaucracy, it is a fruitful exercise to review all of the use cases outlined in this article and examine the processes in place in the organization. What do people do today to achieve these goals? Are there inefficiencies or misalignments happening? Is there room for improvement? How could it be done better?

A learning organization performs regular introspection of this sort and improves based on the findings. Product leaders should help trigger that introspection. Of course, individual product teams should run regular retrospectives that can help unearth some of these improvement opportunities, but leadership should not rely exclusively on that but instead proactively review these processes as well. That way, combining a bottom up and top down approach, you will most effectively improve your processes.

And of course, you are never “done” setting up processes. Teams evolve, the organization grows, key stakeholders change, competitive dynamics shift, and suddenly what was working well yesterday isn’t working so well anymore. The kinds of processes outlined in this article will remain, though. I hope the structure helps improve processes in your organization.

I hope this article was helpful. If it was, feel free to follow me on Twitter where I share thoughts and articles on product management and leadership.