South African businesses are grappling with some very real challenges in bringing an evolved version of product management to their operational environments.
By Jaco Viljoen, principal consultant and head of digital at IndigoCube
A lot of 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 our organisations are actually struggling to catch up with what’s possible and what customers want.
Businesses with a strong innovation capability are adapting best and fastest. Our financial services sector in South Africa is among the leaders. But even in those businesses it takes time. They’re large, they employ thousands of people, many hundreds 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 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 of a single product element.
Regardless of how they establish their cross-functional, agile, responsive capabilities they still encounter many similar complications on their journey to agile product management.
Requirements lists are one.
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.
Requirements lists are a part of the project way of thinking. Business analysts would ask business or operations people what they want to see in the new products. Market research, surveys, polls, as well as interviewing salespeople and customer relationship employees would all or partly be used to determine what was included. It also often comes down what the “business owner” wanted.
The snag is that we have learned that you actually cannot ask people. We learned this the hard way and a lot of 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. We 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 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.