How to transform to Empowered Product Teams – FAQ #3

Q: For years now our technical architecture and platform have limited us to use component teams. We are excited by empowered product teams, but because of this setup we experience barriers to getting started. What can we do to change this?

Each of our teams is typically responsible for one or a few modules in our platform, which makes us struggle a lot with dependencies. When we plan we try to slice functionality from the customer’s point of view, but getting features out often becomes very hard in practice. We don’t always know how to anticipate changes and thus find it hard to be proactive, both in terms of upcoming functionality and from a technical point of view. We are in good spirits and feel we are slowly making progress, but we can also feel overwhelmed at times.

This post is part of a blog series where we answer real common questions in organizations that we have come in contact with and want to transition to an empowered product teams model. Each blog post answers one frequently asked question.

For an introduction to what we mean by empowered product teams, watch our free webinar recordings on our Crisp youtube channel – Crisp Academy.

Answer:

As hinted at in the question, this is a complex and challenging situation. It is also one that in our experience is relatively common. Before we talk about options, let’s first understand better how this situation can develop.

How component teams emerge

In an entrepreneurial startup type phase, the product focus is to solve customer problems quickly to generate revenue. The immediate need is to help the company survive and to validate a viable market fit for the young company, and its emerging product. An initial technical architecture is often generated based on the current envisioned customer needs and constraints. As the solution emerges, through initial successes and often a series of pivots based on initial market feedback, different technologies are tried and integrated.

If the initial architecture that emerges from this process is one of different technologies used in different areas of the product, the stage is set to potentially develop into a component team setup.

As the company grows and its runway stabilizes, through increased revenue or potential new investments, there is room to hire more people. This allows your product offerings to expand in response to previous traction in the market and new ideas for how to expand your product offerings.

As your company transitions into such a market fit phase, different parts of the product are typically developed at different paces. Product areas that need help will see more hires, and the technology in use there will be part of the hiring criteria. The new people, with those specific technology skills, will work together in those product and technology areas, forming teams for those purposes.

The focus in this type of phase is on developing your market fit, not necessarily on preparing your company’s technical platform for a major growth phase. The cultural feel in this phase is typically one that is very high in “can-do playmaking” and “sense of urgency” of getting solutions into the hands of paying customers, typically while being short handed in some areas.

The key point made here is that even if your company has highly experienced tech leads & senior product leaders, with the insight and skills to consolidate and evolve your technical architecture as new customer problems are added to the picture, there is rarely in practice a top priority to do so, so time available for such efforts may be slim.

As the company and its product offering matures, and growing demand follows, a situation can emerge where getting new versions of your product to market becomes increasingly slower and harder. At the same time you are seeing less and less return on just adding more people. As learning curves have increased, so has the size of your effort creating diminishing returns. As a consequence, both productivity and traction is hurting, just as described in the question above.

When you find yourself in this situation, your company is starting to really struggle to scale. If you don’t start dealing with these challenges in a different way, you may experience hitting a growth wall where your product market share flattens out.

Some companies have leaders who see this coming, and can be more proactive. Others don’t, in which case a more costly recovery may be required.

Emphasize product focus

If you are a growing startup, it is likely that you experience the limitations of a component team setup at the same time as your product market fit has started to settle in. You may now be seeing exactly in what customer segments you can be potentially much more successful.

If that is your situation, this is the phase where it becomes very important to narrow your product focus by consolidating and trimming opportunities into these core “actionable segments”, and start focusing on the top problems to solve in those segments.

This means entering a phase where you double down on your highest potential. And with that, start rolling out your emerging product positioning that will sustain your growth phase.

The flip side of this means deliberately stopping investments in tried niches with limited fit, even if there is limited revenue in those niches. This can be a challenge to justify, so gaining the right insight into why this is the right call will be helpful.

A clear way of thinking about what you are doing is that you are entering a phase where you want to validate that your company, and its product, can prove that it can grow in one clear segment where you know there is demand.

For a growing startup, this will be a different goal compared to previous stages, where the emphasis used to be proving that the emerging product could validate sustainable demand in any customer segment. A situation that used to require probing multiple segments.

Successfully transitioning a growth phase requires something different, to develop several very new capabilities at a company level, each requiring its own focus. Capabilities that are needed in order to scale, many of which are well illustrated by the product operating model.

So in a way, this transition is about taking on a different challenge than the previous phases in your company life journey – one of setting your company up to be able to scale with quality.

The transition of focus that I illustrated above is slightly different when you instead are an established company that is developing a very new product. In this case there will be many similarities, but potentially some complementary challenges.

You may have a more forgiving financial situation compared to the growing startup. However you may need more focus on for example stakeholder relationships and aligning your product strategy with the rest of your larger corporate body. Key points to resolve here could be business viability, branding challenges and aligning opportunities with the rest of your corporate product portfolio.

…through product vision and an actionable product strategy

The tools you have to establish this clear product focus are mainly a very clear idea of what market verticals where your company and product can be successful.

As mentioned, this includes sharing your market learnings and then highlighting clearly what actionable customer segments your product will be focusing on to grow in, and specifically why. These insights, combined with a clear opinionated story about what type of product you believe is possible to realize that could potentially change the market, can form the backbone of a tangible product vision that mobilizes engagement and will help your product organization make decisions.

Once your senior product leadership is aligned on what this product vision includes, and can communicate it with one shared voice, you develop a starting sequence of customer and business objectives that forms a practical realization of that vision in the near term – a product strategy, typically broken down into the next several quarters.

We recommend framing your product strategy as a sequence of high level problems to solve, each clearly connected to potentially different areas of an envisioned customer experience, and each with its clear measurable success metrics.

From here, your product managers and product leadership can collaborate on breaking these down into product team objectives and solution ideas that can be sequenced into team roadmaps.

Establishing a strategic quarterly rhythm and/or an outcome based tactical rhythm, that is shorter than a quarter but longer than your team iteration length, is often helpful to bridge the gap from strategy to action expressed through daily work at the team level.

Revised Model Architecture & technical gap analysis

The above work on product focus, and emerging product strategy that follows, can often lead to a new desired team topology. By team topology we mean a set of team objectives each suitable for a product team to take ownership of. Such a desired topology can start to emerge as clear, but it may be one that you still can’t organize easily into because of the current structure of your technical platform.

You probably knew when starting to read this article that creating a new model architecture would be one key step to address this situation.

Good solution design is a clear response to the problem to solve. A solid product architecture for the future, is an envisioned response to what customer and business problems we are expected to solve in the future. That means, we design for things we know we are very likely to actually need, and no more. Doing the above homework on product focus, vision and strategy is what allows the people developing that architecture to make clear decisions on what your architecture will need to support and what it can ignore.

For example, the functional capabilities of a model architecture are highly dependent on the domain problems you expect to have to solve. The better you understand these, the more confidently you can narrow down your architectural options.

A very good way to get a high-level start on what these might be is to do a customer journey mapping based on the product vision and near term product strategy. A good product strategy will give you the input you need to lay out such a customer journey, especially if your senior tech leads do it together with your head of product design or equivalent.

The non-functional requirements of an architecture, which is important to realize may have to change over time, can only be assessed with confidence if the targeted customer segments are well understood in your product strategy. For example, an estimation of the size of the targeted market may help ballparking performance requirements, and insights into relevant compliance and security requirements in that market will inform your corresponding architectural choices.

Once you have such a high-level model architecture well described, your next natural step is to start identifying the gaps between this envisioned future technical platform and your current situation. These gaps can be both in the structure of your product’s software itself, as well as in your enabling infrastructure or delivery pipelines and supporting toolsets.

Aligning technical roadmap with product roadmap

Your architectural gap analysis combined with your insights into future potential team topologies will create a list of activities to address these gaps. These are organized into a technical backlog.

To do this well, a couple of important qualities are needed.

The first is strong collaboration between your CTO (head of tech) and your CPO (head of product). Your product strategy, meaning the sequence of customer and business objectives, needs to be well informed by what your technical capabilities are at each step in this transitional journey. For example, it will often be the case that key pieces of the technical backlog will need to be completed to enable key customer or business objectives to be worked on.

The second important quality needed to do this well is slicing. By slicing we mean the skill of dividing up larger pieces of work into a set of smaller pieces each easier and faster to tackle on their own. This is a skill that is needed for all product leadership skill areas – product, technical and design, to allow driving gradual change without interrupting the flow of customer value and while preserving short lead times to market.

With slicing skills and with a collaborative focus on achievable valuable outcomes, your product leadership over time – through planning briefback mechanisms that levels demand to capacity – gradually evolves into a roadmap that is well aligned with your product strategy and that is also realistic where technical enablement precedes and allows customer problems to be solved.

A common anti-pattern we often see at Crisp is to stop customer value flow completely for a longer period of time, in order to focus only on technical improvements or platform work. This pattern has many drawbacks, and typically results from a combination of lack of strategic focus, insufficient model architecture and gap analysis work combined with lack of slicing skills.

Beyond the more technical gaps, and initiatives to close them, your technical roadmap will likely also need to include initiatives to upskill your staff, accelerate adoption of new practices and potentially hire people with key skill sets needed to complement your current organization.

Identify and evolve into your desired team topology

As your technical architecture evolves over time, different areas of your technical platform will start to become more independent and self-contained from the rest of your product. As this happens, you can start to organize into new team objectives where your product team can take more ownership and work more independently from other product teams.

This is primarily a result of aligning technical structure to new clear customer areas of focus, each with its own less dependent architectural response.

If you are familiar with Conway’s Law you can see the idea here. We are using it in reverse, by aligning our solutions with the problems to solve, and then organizing teams around those partial technical problem-solution fits. When you establish enough cohesion and decoupling you can spawn new teams responsible for those now more loosely coupled areas of your technical platform.

Each such team can then much more easily work on complete feature slices with a clear customer focus, without depending on all other teams in order to release.

Summary

That was a lot of ground to cover, but hopefully something you can find helpful.

If you have any questions you want answered, feel free to contact me and I may write about them in a future article.