A Product Development Framework With a Focus on Problem Solving

In my last role as head of product and engineering for a group developing cloud-native services for the SAP Cloud Platform, my work led me to define a framework for product development that spans both product management and engineering and brings with it a focus on problem solving through the product lifecycle.

In case you haven’t realised it, building computer systems is hard. Martin Fowler

Experience teaches us that software product development is more of an art than a science, and building great products is more about people than technology. Things may be black or white at the circuit level, but the higher we go in the ladder of abstraction, the more grey they become. Two teams may use the same flavour of Agile but produce very different results. The practices used to build complex software can sometimes seem random, guided more by individual (or team) preferences than solid engineering principles. Development cycle recommendations range from weekly, biweekly, to monthly or weeks. Who do you follow?

Often, it’s context that gets missed. Applying the software development practices without considering the context – specific to your domain/industry, work culture, and your local constraints and goals – is an invitation to failure. For instance, if you’re developing software for a nuclear-power plant, then rigidly placing “working software over comprehensive documentation” (as the Agile manifesto puts it) is perhaps not the best option. In an unstable environment with frequently changing boundary conditions, enforcing the OKR approach will only lead to frustration. And stakeholder management strategies differ widely depending on the work environment and company culture.

The following framework is based on my experience in the last three years. Until very recently I led several product teams to develop cloud-native services that formed parts of the SAP Cloud Platform, an enterprise PaaS solution from SAP*.

But first, here’s some context.

Context

The group is part of a larger ecosystem that includes, among others:

(a) platform services being developed in other organisations

(b) lines of business building apps on the platform

(c) central architecture and operations teams doing governance and operations

(d) teams providing in-house tools.

A complex stakeholder matrix influences what the group builds and how we build it. The group caters to an existing customer base, which means a greenfield approach is not possible: often the group’s services have to fit into an existing toolchain or process these customers use. It also means it’s not possible to independently imagine new services into existence or target new markets – frequent validation with existing customers and partners in the SAP install base is key.

Despite the trappings of a large company, the group operates like a startup. Most services are incubated and shaped for the external market (and not driven based only on internal stakeholder demand). The group is responsible for the success of the products it develops, with the freedom to choose the tools and practices needed to achieve this success.

The Framework

Across the different teams in the group, it’s useful to break down and categorise the product development lifecycle into problem-solving categories. Not phases that follow each other as in a waterfall, but simply different classes of problems we need to solve:

This structure evolved as we gained experience in conceiving and building new services. Once there was a grip on the patterns (the common problems teams were solving, the categories they fell into, the roles working on them) it was natural to put them together into a single, larger framework.

The framework categories are not phases in the product development lifecycle (even though some may appear so). The boundaries are fluid, and an overlap of activities across categories is common. Getting stakeholder buy-in may need work from design and architecture; strategy needs to be validated with customers using examples or prototypes from design. Such specifics depend on the nature of the problem space and the solution being considered. And clearly, iteration may be needed. For instance, failing to get buy-in the first time could mean returning to the strategy question and tweaking the hypothesis before getting it validated again with customers. Issues in delivery may necessitate revisiting the question of our branching model in the CI/CD environment.

Framework Characteristics and Benefits

Problem-solving Focus

The framework highlights the nature of problems the group solves through the lifecycle, from conception to maintenance. Structuring and phrasing it in this way avoids thinking only of deliverables or features. Instead, the idea is to regularly ask: What problem are we trying to solve here? Has it been solved by someone else? Framing activities as “problems to solve” gives everyone in the team a better handle on what they are trying to achieve. Without this focus, it’s easy to get lost in the details of achieving a “key result” (to use OKR terminology) without really understanding – and perhaps questioning – its purpose.

For instance, reusing a central service can be managed better when the task (say, set up a CI/CD pipeline) is framed as a concrete problem to be solved. Understanding that problem may reveal that the central service is unsuited for the team’s purpose (perhaps due to the technology stack used). On the other hand, framing it as just a task for the Scrum team runs the risk of the assigned team member merely following a routine to complete the task. A simple shift in perspective – towards looking at the problem – can lead to radically different results.

The focus on problem-solving also reduces waste. When asked to create a report for someone in senior management (not uncommon in a large company), the group can  instantly see that this does not really solve any problem. Understanding this helps to spend less time on such activities.

This change in mindset is best approached holistically, across the product development lifecycle. And following the framework is a way to introduce this culture within the teams.

Product and Engineering Together

The framework spans topics that come typically under Product Management and Engineering: there is no separation between the two.

There is also no strict mapping of responsibilities (of Product and Engineering) to problem areas  – both have a role to play across the lifecycle. For instance, architects can play an active role in strategy definition (they are sometimes the source of ideas that lead to new services), and product managers can have a say in delivery architecture (to ensure it meets the business goals defined).

In his book Inspired: How to create tech products customers love, Marty Cagan refers to this separation between product and engineering as a missed opportunity: “The little secret in product is that engineers are typically the best single source of innovation; yet, they are not even invited to this party…”

Achieving this synergy is easier with both Product and Engineering in the same organisation, under the same head.  In this case, Product and Engineering are closely knit – even sitting in the same rooms, part of the same meetings – which leads to better communication and understanding across the two roles.  Defining the right pricing metrics, for instance, needs close collaboration between the product manager, product owner, and architect, and this is not a one-time activity: several iterations are needed to get them right. Treating this problem like a project spanning organisational boundaries would be suboptimal in comparison.

Even when Product and Engineering are in different organisations, a common framework can act as a scaffolding holding together the two silos, thus enabling better collaboration.

Big-picture View

For anyone responsible for a medium-sized portfolio of products/services (say, eight “teams of 10”), there are dozens of tasks seeking your attention at any point in time — how do you judge what to take up next, what to parallelise, what to postpone?

The framework shows a way out, by presenting a big-picture view of the product development lifecycle. Across a portfolio of services, it can also be used as an assessment tool to see what problem areas are still open and where good progress has been made. The group has had cases where buy-in from a stakeholder was excellent for one service but other services were struggling – the assessment brought this to the open, which helped the teams talk to each other and rethink their approach toward the stakeholder.

As someone leading several product and engineering teams building services (each in different lifecycle stages), the framework has helped me to get a handle on the problems I needed to focus on at any given moment. The big-picture view is essential for this; without it, I could easily get lost in the details.

I also used it to conduct business reviews of the services in my area. Each review was structured along these categories, and the teams came up with a summary (for the service they were building) of each problem area. Presented this way, it was easy to see which team was getting something right and who was struggling with a problem area. The resulting transparency across the teams created many opportunities to learn from one another.

The big-picture view benefits all roles in the team, not just the lead. Developers gain insight into the business value of the code they are writing. This alignment with the business goals is key for a well-rounded product (and is easy to miss unless there is an explicit focus on it). The developers also get to see what else — beyond coding — is needed to get their product or service to the market. We sometimes asked developers to join our customer interview sessions: teams with this practice showed a better understanding of the product/service they were building.

Used in this manner, I’ve found that the framework is a highly effective communication tool.

Summary

The framework offers a big-picture view of the activities broadly needed to conceive a new product, develop it, and take it to the market. It adopts a problem-solving approach to structure these activities, and includes both Product and Engineering domains.

Approaching the software lifecycle as a set of problems to solve radically changes the nature of conversations in your teams. The rigour this introduces leads to better decisions, an improved grasp on managing priorities, and a change in mindset that leads to less waste. Viewing both the product management and engineering as parts of a single frame breaks down barriers that often exist between them. You begin to see how both roles can contribute throughout the lifecycle, resulting in a better product.

The framework can be used as a blueprint while starting a journey to build a new product, but one doesn’t have to follow it religiously to benefit from it. Think of it as a guideline, something to internalise and use as a checklist. Use it also to structure the portfolio of products you are building. The framework is an effective communication tool, a common way to present all products/services in your area, and align all teams with the big-picture and the business goals. Use this structure also to assess, across different problem areas, the relative strengths of your product portfolio.

And depending on your context, tweak it.

* While this piece refers to my recent experiences at SAP, the views expressed here are mine.