I lead product management and solution architecture at a software development company here in Austin, Texas. When I started a few years ago, product management as a practice did not exist at this company…and there were problems that the founder anticipated product could solve for our clients.
Fast forward a few years, and I’ve been considering: How is Product Management at a dev shop different than at a company that develops its own software products?
At most companies, Product Management tends to focus within the bounds of the company’s vertical, such as education or healthcare. At our dev shop, we partner with companies from a gamut of verticals to design and develop their products. Given our clients know their respective verticals and by extension their customers infinitely better that I, what value can I bring?
Working across so many domains, it turns out I have the unique perspective of seeing customer pains addressed over and over through products and their features. Over time, I’ve been able to distill out common successes (and failures) of the solutions, turning that experience into product guidance for every new client. Even knowledge of existing open-source and OTS (off the shelf) solutions used in one vertical prompts consideration for reuse or exploration within another vertical for possible solutions.
In short, I have become a consultant to our clients, lending those common solutions as we think through the desired features together, ensuring the task of reinventing a wheel isn’t undertaken, or at least without sufficient warning.
PM Maturity: Everyone is Different
Successful product managers must know their customers and business. In my case, every one of my clients should have at least one person who plays this role, even if not officially titled product manager. This is where things can get tricky, as not every client employs experienced or trained product managers.
As the product management counterpart for each client, I meet them where they are today, each at their own level of product management maturity. I’ve become well-versed in asking the right questions to distill out:
- how well they understand the problems that need to be solved for their customer and business
- the requirements that have been validated by their customers, and thus,
- where they are making assumptions
Organizations with mature product management have this worked out, but others may need quite a bit of hand-holding through multiple conversations. It is in no one’s best interest to build the wrong features, or build the right features at the wrong time. As we figure out the roadmap, often my job is to think through and push back on proposed features to ensure the client is planning features that their customers want while fulfilling their business goals.
Quite a bit of my role overlaps into solution architecture, which is where my broad technology background and software dev experience tends to pay off. As I meet our clients during pre-sales and after the project commences, it’s helpful to know where the gotchas are fairly quickly, navigating the conversation to investigate further.
Example: the client wants to build a car, and desires the following features: wheels, windshield, steering, engine, radio, seats, and hover capability. It’s helpful to be able to state immediately that all but the last are fairly standard, but the final one requires orders of magnitude more time & resources. At this point, we can dive into that feature requirement and see if it’s truly necessary, or see if the root problem can be addressed in another less taxing way.
In addition, as the product management counterpart to our client, I have think through the features they will need for a successful release, including anticipating the back-office administrative roles and features which most clients rarely anticipate. Thinking ahead to how the client, given their own business processes + sales & marketing plans, will need to engage with the product post-deployment, cannot be underestimated. Surprised clients, in this scenario, is not a good thing.
Finally, as I alluded to earlier, when I interview clients to understand their business goals and customer problems, I naturally consider solutions I’ve already seen…whether partial-solutions as OTS software, or software products that exist in other domains. I often break down the customer problem and consider solution made up of OTS and custom components, all of which can be investigated by our design and development teams as a potential path for implementation. It’s a starting point for the internal conversations, and gets everyone thinking about development costs, cost of ownership, performance, integrations, and the like.
Client-Facing, by Nature
If there ever was a role that is client-facing, it’s product management at a dev shop. While traditional product management is encouraged to spend time with customers, there is hardly a day that goes by when I’m not speaking with a potential or current client.
Being genuine, friendly, professional, likable, transparent, and an excellent written and oral communicator are all required for this role. Most of our clients first engage with our dev shop via product management, and therefore we are the first impression. Then, collaborating with our internal UX design and software development teams before in pre-sales, as well as during the project, is imperative.
Suffice to say, in product management, it helps to be a people-person, and no less so at a dev shop.
Every software company must have some software development process to create products. Because dev shops are typically managing numerous projects across one or more clients, they live and die by process.
At our dev shop, we practice our own flavor of Agile Scrum. Clients hire us to develop software for them, and for many, this relieves them from building their own UX design and software development teams, and associated methodology. This also means many clients have no idea what “Agile” or “Scrum” is, and may themselves be accustomed to a traditional waterfall mindset of project execution. Training clients about the benefits and drawbacks of Agile is often required initially and throughout the project. This is a big difference between dev shops and traditional software companies, where the latter is presumed have all bought-in on a methodology.
In addition, the three pillars of a project (time, budget, scope) become quite literal when working with clients. If any or all of the three pillars were tied down contractually, product management must manage this with the client, and decide how to handle inevitable changes that occur during the project jeopardize success.