At workshops for product leaders, we often discuss different approaches to implementing major organizational changes within product management teams and adjacent groups (e.g. Engineering). Not surprisingly, the general answer is “it depends” on lots of factors. But worth recapping some of the choices and their implications.
First, a nod to Saeed Khan, who points out that there is no universal, perfect organizational model across all product teams and all situations. Paraphrasing:
And recently, a product leader at Spotify shared that her group (and many others throughout her company) have evolved to very different organizational models than described in Henrik Kniberg’s 2012 Scaling Agile @ Spotify. I’ve repeatedly seen that cutting and pasting someone else’s organization ignores the hard retrospection about what’s not working (and what works well) at your own company.
Once we (as product leaders) have chosen a new product organizational model, we also need a strategy to get there. Big bang? Incremental team by team? Optional participation? Changing how a product management team divides its work – and how it interacts with development/design/marketing groups – is as much about change management as org charts.
So I’ve laid out two broad examples of organizational shifts along with ideas for rolling them out. I hope you’ll see that one size does not fit all, and that understanding your current organization is essential to planning any transition.
[1] Professional Services Projects → Stable Product Teams
It’s typical for professional services firms and custom development shops to have project-based resource pools. As each new project arrives, we form a short-lived team for that project based on perceived needs and staff availability. On completion, that team is blown up and we form new project teams. The company makes money by marking up development/design time, so there’s strong incentive to start new paying work as soon as current engagements finish. And services firms usually don’t have product managers: instead, individual clients tell us what they each want and we profitably custom-build that. No need for market validation, ROI calculators, competitive analysis, per-seat pricing models, or multi-release roadmaps.
But many services firms say they want to get into the product business: build something once and have many customers pay for that identical bit of tech. It’s almost free money! In reality, they rarely get any products launched, since the (theoretically) dedicated members of that product team are repeatedly pulled onto current-quarter project work to deliver current-quarter revenue. Bits of unfinished product float around with a rotating set of part-timers picking up and dropping them again.
What’s A Better Approach?
I’m a rabid supporter of long-term-committed whole product teams: we assemble a two-pizza group of developers, designers, product folks, and test automation engineers who will stay on their assigned product through many releases and nurture it. They need to deeply understand their end users as well as buyers, own their own bugs and tech debt, work through a strategic backlog from v1.0 to v3.0 to v8.3, and focus on volume sales rather than single customer demands. In a real sense, the team is synonymous with the product.
How Do We Get There?
We could simply declare ourselves to be a product company, and assign everyone to newly unfamiliar roles. Big bang. Before announcing any organizational change, though, it’s worth guessing at likely objections, pushback, skill differences, and cultural norms. Your situation may be different, but at services firms I see every process tuned to say “yes” whenever a client wants to pay for something. Sales brings in a prospect, we size the work, and we jump to deliver a uniquely bespoke solution for that one company. Company metrics are about project-based margin and keeping our development organization busily billing for their time. That’s diametrically opposed to how product companies think – product companies want repeatable, low-friction installations with as little handholding as possible, in order to sell hundreds/thousands/millions of users a single codeline at prices well below what customers would spend to build it themselves.
So we should expect tremendous organizational resistance to a shift from service approaches to product approaches:
- Sales teams trained and rewarded to bring in whatever a client says she wants, instead of finding buyers interested in only what we’ve built
- Development staff used to cycling off projects at completion, with little emotional connection to end users or long-term commitment to supportable code
- Skill gaps among the current staff: no experience critically validating product concepts; sizing market segments (“How many different customers need this exact thing and how much will they pay for it?”); estimating real business impact in measurable units; pushing back hard on one-offs and specials.
So One Possible Approach…
We might create one whole development team, assigned to one hand-picked product. That team would include key folks: developers, designer, architect, test automation engineer, tech docs. And since we’re unlikely to have anyone internally who’s successfully managed commercial software products through multiple releases, we’ll go outside to hire a seasoned, politically savvy product manager who already knows how to shepherd teams/products from concept to delivery.
And anticipating that executive behavior will be our biggest challenge, we’ll need a C-level product leader to hold back the C-level interrupts. Within the first few weeks of this team’s existence, we’ll see dozens of escalations to company execs of professional-services-style demands: “Project Zed needs a front end developer, so we’ll borrow from the product team for just one week” and “Big Client Y wants almost what the team building, but needs it on-premise instead of in the cloud, so we’ll tweak the architect a tiny bit” and “I have a product idea that’s even better than what we’re building: let’s investigate that instead.”
IMHO, the top failure mode for product teams within services companies is that they are not allowed to finish anything. Every day brings new interruptions and new opportunities. So some product-savvy executive needs enough clout to defend our very first product team.
This may take a couple of quarters or more, since building repeatable products is different from single-use project work. Once we’ve gotten something out the door and achieved a tiny bit of market success, we can talk about forming a second product team.
[2] Narrow Scrum Product Owner → End-to-End Product Manager
I’ve written and spoken extensively about how IMHO narrow Product Owner definitions don’t encourage successful commercial software products. Introductory scrum books focus on transactional product activities – writing stories, re-ordering backlogs – assuming that product strategy and market insights magically arrive from outside. In my view, every product person should spend roughly half their time listening directly to actual end users and prospects. (Unmediated by stakeholders, proxies, sales teams and industry analysts.)
When dropping into companies as interim CPO/VP Product, that’s one of the first things I consider. I want to broaden product owner roles into end-to-end product management roles: with each product person responsible both for inbound work (prioritization, problem definition, goal setting and stories for a single team) outbound work (direct market-sensing interviews with live users, deep learning, market validation, value-driven Jobs To Be Done, competitive analysis). This is a big shift in time and emphasis.
But How Do We Get There?
It’s not enough to simply declare that a product owner team suddenly has much broader responsibilities and needs to start gathering its own direct user/market insights. We’re likely to run into:
- Major skills gaps, where POs have been hermetically sealed in development-facing roles. Most will lack interviewing experience, outreach tools, and comfort re-interpreting surface complaints into underlying product problems.
- Pushback from Sales and Business Development teams, who are used to writing requirements themselves. “We talk with customers all day long, and know what they want.”
- Slow improvement. It may take a quarter (or two or three) for a steady stream of direct user feedback to shift attitudes and product plans and churn rates. Insights take time. Meanwhile, falling back to the previous model is a daily temptation.
- Product management changes don’t speed up development. I hear endless executive complaints that Engineering teams are too slow or unproductive, although I almost never find that true in practice. It takes time to demonstrate that building the right few things – with product managers ruthlessly de-prioritizing everything else – is how we put more effort against real value and waste less on shiny objects.
So One Possible Approach…
I like to pick one high-potential product owner and their dedicated development team for a pilot. Get started, uncover issues or barriers, adapt as we do. Call it an experiment, uncover organizational stumbling blocks. And I plan on some intensive personal coaching/mentoring on experience-driven outbound work:
- Working together to defining outcomes versus output
- Outside training on validation techniques, interviewing, Jobs To Be Done (from Teresa, Holly, Hope…)
- Instituting dev-team-level sharing of user inputs and market insights
- Lots of practice translating technical features into business benefits and sales-friendly vignette
If we do this well, most of the product and development organization will see goodness and want to join in. (See Tom Sawyer and fence painting.) Along the way, a few current product owners may request development or project management roles instead of this mixed outbound job.
Sound Byte
Organizations are complex and change is hard. Simply publishing a fresh org chart or announcing a new set of responsibilities doesn’t make it happen. As product leaders, we have to understand our own situations, blockers and talent pool. Then craft a plan to “sell” change while implementing it. This sounds a lot like applying agile thinking to organizations.