SA businesses are figuring out how to do product management better
The definition is important because it affects the roles people fulfil, what roles even exist and how those roles are executed.
South African businesses are grappling with some very real challenges in bringing an evolved version of product management to their operational environments.
Many people know and understand that product management in the digital era is a very different animal from what came before. Digital has changed everything so quickly and so profoundly that organisations are struggling to catch up with what’s possible and what customers want.
Businesses with a strong innovation capability are adapting best and fastest. SA's financial services sector is among the leaders. But even in those businesses it takes time. They’re large and they employ thousands of people, many hundreds of whom are involved in the software development process and hundreds more in the related business function.
Certification based on international best practice helps because companies have to deal with so many different aspects that it could take a lifetime to learn and integrate independently. Hierarchies, silos, business units and divisions, even merged entities, branches and, most importantly, customer expectations all compete for attention.
It’s clear that many organisations still grapple with exactly what it means to be a product manager in the digital era, in the context of their business and their market. The definition is important because it affects the roles that people fulfil, what roles even exist, how those roles are executed within the overall business, and to what extent they’re encouraged to permeate the organisation. They also just plain need to know how everybody works together.
There are various ways
Some organisations have niche roles focused on specific elements of the product journey; others have generalists who work alongside their more traditional colleagues; and others have cross-functional members who also specialise in, and take responsibility for, a single product element.
Regardless of how they establish their cross-functional, agile, responsive capabilities, organisations still encounter many similar complications on their journey to agile product management.
Requirement lists are one such complication
People are accustomed to the project way of thinking. That means things like timelines, budgets, requirements, goals and resources. Projects are useful things, but in the world of software development and by association, product management in the digital era, they’re slow, unresponsive and cumbersome.
Requirement lists are a part of the project way of thinking. Business analysts will ask business or operations people what they want to see in the new products. Market research, surveys, polls, along with interviewing salespeople and customer relationship employees, will all or partly be used to determine what's included. It also often comes down what the “business owner” wanted.
The snag is that companies have learned that you actually cannot ask people. They learned this the hard way, and many software developers and IT departments have done the same. People don’t actually know what they want, even though they’ll tell you they do. One can’t blame them. Nobody has a crystal ball.
That’s a nugget of truth; that nobody has a crystal ball. You cannot know what the requirements are upfront. It’s a powerful message encapsulated in the approach that puts experimentation on the table. What that does is provide you with a platform to build something small, put it out there and very quickly get the feedback you need to decide if you’re on the right path.
If you are on the right path, you’ll likely gain additional requirements rolled out in new features in future releases. If you’re on the wrong path, you get to pivot by rethinking your product.
At the end of the day, it puts you in touch with your customers and keeps you close to them. And that’s essential in today’s fast-paced, always changing world.