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:

Discover & deliver (in product teams)Align the broader product organizationCoordinate with stakeholders across the org

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:

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:

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:

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:

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.