What business analysts need to know about the product operating model
An increasing number of organizations use product management for the software they build for their own use. Here's how business analysts can take advantage of that trend.
Originally published in BA Digest Q4 2024 along with some fancy origami animals. If you’re interested in topics relevant to business analysts, check out the full magazine.
During the past 10 years, software has become much more pervasive in organizations, especially those not normally thought of as “tech companies”.
This is especially the case in industries where business analysts are most common: insurance, financial services, retail, healthcare, and government.
In order to adopt into their day-to-day operations, many organizations undergo a series of transformations.
These transformations try to emulate ways of working from other industries, often ones that do not widely use business analysts. The result is business analysts can often get left behind in the change to their, and their organizations, detriment.
It doesn’t have to be that way.
The latest of these transformations - the switch to a product operating model - provides an opportunity for business analysts to make substantial contributions.
To explain how, I need to explain how we got to where we are.
First agile, then digital, now product
In a broad sense, there are the three types of transformations that organizations have gone through to become more tech enabled:
Agile transformation - When IT develops software for us, it seems to take so long, and have so many issues. How can we go faster?
Digital transformation - Hey, now that we can build software faster, perhaps we should view IT as an asset rather than a cost center. Maybe we can use it to automate our processes and help customers self serve.
Product transformation - Wow, we can build stuff fast, but more often than not, it’s the wrong stuff. We ought to figure out how to decide what stuff to build.
When organizations go through a product transformation, they may describe it as going from projects to products, or focusing on outcomes rather than outputs. What they’re doing is adopting the product operating model for their change efforts.
What is the product model, really?
Marty Cagan, with Silicon Valley Product Group, described the product operating model this way:
The product operating model, also referred to as the product model, is a conceptual model based on a set of first principles that leading product companies believe to be true about creating products.
The product operating model is about consistently creating technology-powered solutions that deliver value to customers and that also drive results for the business. It’s about achieving outcomes versus merely producing output.
When your organization adopts the product operating model, you’re changing how you decide which problems to solve, how you solve problems, and how you build solutions.
How you decide which problems to solve
The product operating model reinforces the need for organizations to decide explicitly what they will and will not build. In addition, it identifies what should guide those discussions - a customer centric product vision and an insight-driven product strategy.
How you solve problems
Instead of being handed solutions to deliver, leaders ask teams to solve problems and achieve outcomes. This gives the people who know most about the technology the latitude to determine the best solution to achieve the desired outcome.
The solution the team finds needs to address four risks:
Value - does your solution benefit customers and will they use it?
Usability - are users able to figure out how to use your solution?
Feasibility - is your team able to build what you need with the time, skills and technology you have?
Viability - is your organization able to deliver your solution at a best-in-class level?
It turns out that viability can be the one risk that gets the short shrift.
How you build solutions
Strive to build software “using small, frequent, and reliable releases of at least once every couple of weeks and preferably using continuous integration and continuous deployment.
Viability and business analysts
The common wisdom is that you have a product trio made of people with different skill sets focused on those four risks I described above:
A product manager who is best suited to pay attention to value (and viability)
A tech lead who is best suited to pay attention to feasibility
A product designer who is best suited to pay attention to usability
Notice I didn’t say those roles “own” or “are responsible for” those risks. The trio works together to address those risks, and it doesn’t hurt when different members bring different expertise.
What is viability? It Depends.
When you work on tech products, viability means the solution works within constraints from other departments, such as marketing, sales, finance, service, legal, and compliance.
When you work on an internal product - software an organization builds for its own use the meaning of viability shifts in a subtle, but important way. The department constraints you’re concerned about are those departments that will use the software you build.
In either case, you can describe those constraints in terms of the rules, data, and processes that make the solution work.
Sound familiar? Right, those are a business analyst’s sweet spot.
So who pays attention to viability?
In tech product settings, product managers can pay attention to both value and viability.
Most product management training includes how to discover your customers' needs (establish
value) and figure out how to create business cases and take the product to market (ensure viability).
Product managers typically aren’t as familiar with (unless they came from a business analysis background) how to deal with rules, data, and processes from internal business departments.
Business analysts can easily fill that gap, either as becoming product managers or, as another member of the trio (which now, I guess, is a “quad”).
That’s not to say you’re getting one of those roles because you’re a business analyst, but because you know how to understand the relevant rules, data, and processes and work with your team to craft a proper solution.
In fact, the chances are the role you fill in this setting may not even be business analyst. It could be product owner, or delivery lead. That doesn’t change the fact that you can leverage your business analysis skills to be an indispensable member of your team.
For example, I was the delivery lead on an internal product that calculated prices for an agriscience company.
Because of my business analysis background, I was the one who dove into the specific pricing rules the new system needed to enable, what data we needed to set those prices, and what the business process would look like to make that happen.
I started off with a series of discovery sessions so the team could get familiar with the organization and the specific activities of setting up prices. Once we had a fairly good basis of understanding, we moved into a pattern of continuous discovery, refinement, and development.
While it’s tempting to describe this as requirements elicitation, it was much more than that. We became familiar with the rules, data and processes that we needed to have in place to set prices properly. We were ensuring the viability of the solution.
Business analysis has a place in the product operating model
A key piece of adopting the product operating model is caring about viability. A lot of what business analysts do is ensure the solutions an organization builds work for that organization.
So if you want to be part of an organization’s move to the product operating model, don’t insist that you should be on the team because you’re a business analyst.
Instead, explain what skills you have because of practicing business analysis and explain how you can use those skills to make sure teams build viable and valuable solutions.
Your value comes in the skills you can apply, not necessarily the title that you hold.