I learned two truths this week.
During the
Coffee with Digital Trailblazers, a LinkedIn audio event that I host most Fridays at 11 am ET, Jay Cohen
shared that January was a good time of the year to focus on learning
programs and driving department and team-level realignments. It makes sense
because people return to work from the holidays refreshed and ready to
learn, while the upcoming year’s new priorities may not have been rolled out
yet.
The second learning came from three conversations with Digital Trailblazers
over the week. One was a large bank, the second a midsize insurance company,
and the third from a small county government office. “We have long backlogs,
coming from the open-a-ticket mindset,” said one IT Ops leader, and another
acknowledged, “We struggle to prioritize our work.”
Agile without true product owners is backlog management
These companies use basic agile practices, but their leaders acknowledge the
organization’s struggles with the product owner role and product management
disciplines.
My suggestion to all three: Use January to roll out a basic,
rudimentary product owner role and product management function.
It’s common to find product managers and product owners in SaaS, technology,
ecommerce, retail, and other B2C companies. Leadership in these companies
long realized that understanding markets, determining product-market fits,
defining customer personas, and understanding value propositions are all key
to developing minimally viable solutions and delivering ongoing product
enhancements.
But identifying product managers and owners in non-tech companies, B2B
businesses, SMBs, and the government remains a long-running work in
progress.
An overly simplified way to introduce product management that can work
I’ll skip writing about why many businesses struggle with product
management. Instead, I will shift to how more traditional, non-tech
businesses and SMBs can quickly shift from a stakeholder or sales-driven
mega backlog to defining market-driven roadmaps and delivering
innovations.
Here’s the high-level process:
-
Identify tangible and ideally measurable reasons why the company’s current
product development approaches for delivering meaningful new capabilities
to prioritized customer segments are underperforming. -
Redefine the stakeholder role as someone who provides input to the
strategy, roadmap, or priorities. Most importantly, make it clear that
stakeholders provide input, not a decision, and that there’s no guarantee
that what they request will be prioritized. -
Broaden everyone’s definition of ‘ ‘product’ as a set of capabilities or
services that are delivered and improved to a customer segment – external,
employee-facing, or both. Then, select one product that everyone can agree
on – a product with a defined customer segment, easy-to-define
customer-product journeys, a known set of tech and non-tech assets, and
operations tied to the product’s marketing, sales, and operations.
I’m pausing here to provide some clarity: Step 1 helps define a
problem statement around what’s not working in the current product
development process, and step 2 creates a clear separation on how
non-product organizations typically function. Step 3 is challenging to do
across a product portfolio, but most organizations can usually find at least
one product that’s easy to define with few grey areas of scope.
Define product management, dedicate a team, and assign a product manager
Now, if you get this far, you’re ready for the next three steps.
-
Share a simplified definition of a product manager as someone who defines
the product vision, creates a set of priorities for their team(s), and
proposes a set of (ideally measurable) success criteria. -
Agree on the people who will be part of the team(s) working on the product
and free up their time to be dedicated to its roadmap. -
Assign someone to be the product manager, relieve them of as many of their
prior responsibilities as possible, and ensure stakeholders acknowledge
that the product manager will filter and rank priorities for the
team(s).
I’m pausing again. Step 4 is simplistic by design, and there are many more
skills and responsibilities to this function, but many organizations can
start with the basics. Step 5 is where many organizations truly struggle
when defining their agile organizations and team structures, a topic I may
cover in a future post. But step 6 is ultimately where SMBs and non-tech
companies stumble.
Internal product managers require training and mentoring
They find it difficult to pick a person, even though many products have at
least one subject matter expert that understands the customer. If they
assign someone to the role, they trip up on freeing them from prior
responsibilities and fail to recognize that the person assigned to the role
needs training and mentoring to learn how to manage stakeholder
expectations. (Note: see my
12 posts for agile product managers
and watch the embedded video as a starting point.)
To start innovating, it comes down to transforming from stakeholder-led
backlogs to product-managed, market-driven roadmaps. Tech, media, and
ecommerce companies figure this out right away because chasing
stakeholder-driven features often yields subpar results. More traditional
businesses are likely to misdiagnose the problems with stakeholder-driven
backlogs as a technology execution or platform issue.
But there are a few secrets to making product management work even in the
most traditional businesses. The key is simplifying and properly sequencing
the 6-step list I just proposed, but how to go about this must be customized
to the business’s culture, organization, goals, and products.
Reach out to me, and I’ll guide you on where to start.
