How To Scale a Unicorn Product Management Team
Why Hire Product Managers and Build a Product Team?
Why hire product managers and build a product team? The short answer is that if you’re a tech company, you need to… period.
In my opinion, product managers can arguably have the biggest potential impact on business and product success, or lack thereof. They are the gatekeepers who decide what features to include in a product if, and only if, the features generate a clear and concrete benefit. It’s all about building benefit-driven and not feature-driven products.
A product manager (PM) is necessary to provide oversight, management, and generation of a shared vision and understanding around all aspects of the product, and to all stakeholders. There are usually many stakeholders that the PM collaborates with. These include company executives, line of business owners (e.g., marketing, sales, customer success, etc.), customers, and so on. The PM’s job, with regard to stakeholders, is to solicit and capture ideas and feedback, provide ongoing visibility and transparency into product decisions and development, properly set expectations, and so on.
Attempting to build tech products without a competent PM often results in disaster. There are a couple of important reasons why a PM is necessary: The first is that people usually think they are the customer or user when in fact they are not, and therefore a PM must represent the voice of the actual customer or user. Second, products tend to get built by the HiPPO method (highest paid person’s opinion) or through design by committee.
Seth Godin has famously said that “nothing is what happens when everyone has to agree”. He’s right. PMs must collaborate with everyone, but not necessarily agree, nor build features just because the CEO says so. The PM must always advocate for the best possible product. This is imperative to product success.
The Purpose of Product Management
Product management is an umbrella term used to describe the process of developing a product vision and strategy, executing and delivering on that strategy, and finally measuring product success. This is usually done in conjunction with analysis and understanding of markets, competition, product market fit, business goals and metrics, product feature ROI, and so on.
A product vision is the WHY behind building a given product, and is intended to fully define and address a given set of goals, needs, and/or problems. The WHY includes all business and use cases surrounding a given product and its features.
A product strategy is the manifestation of the product vision in the form of a product roadmap, which is further manifested in the form of predetermined feature releases or continuous delivery. Finally, the roadmap consists of product artifacts such as epics, features, user stories, requirements, acceptance criteria, and so on.
In a tech product company, product management as I’ve described is usually the responsibility of one or more PMs and/or analysts, collaborating with stakeholders and a product development team. The product development team, in the case of connected smart solutions (discussed more later), can include UX and UI designers, hardware and firmware engineers, software architects and engineers, QA and automation engineers, data scientists, and so on.
Top tier PMs that have the requisite product management expertise, experience, and soft skills such as leadership, effective communication, and empathy are very hard to find. As such, the PM role has become quite coveted and highly compensated.
Product Management of Connected Smart Products
It’s worth noting that everything discussed so far is only in the context of PMs and product management at typical tech product companies (e.g., SaaS), which usually do not build end-to-end fully connected smart solutions.
I used to run the product management and advanced analytics disciplines at Rocket Wagon, a services company building connected smart solutions for enterprise clients. What makes them unique is that they are able to ideate, propose, design, build, and deliver best-in-class connected smart solutions, end-to-end, and all under the same roof. Connected is a term synonymous with the internet of things, or IoT.
This means going from an assessment of customer needs and goals to then creating a transformative, connected business strategy. This is followed by executing on that strategy to create a fully connected smart prototype and pilot, and then assist with full-blown commercialization and scale where needed.
This requires core competencies such as UX/UI design, hardware design and engineering, hardware prototyping and optimization, connectivity and communications, firmware design and engineering, software architecture and engineering, devops, reliability engineering, data ingestion and processing, advanced analytics (e.g., data science, machine learning, and AI), and commercialization and testing.
Doing this successfully isn’t easy though. Perhaps you’re thinking that for a services company, why focus on product management so much? Shouldn’t the conversation be more in terms of consultants, engagement leads, account managers, associates, analysts, and so on? The answer is no. Building bespoke, end-to-end connected smart solutions requires an extremely product-first, product-driven company (services or otherwise) and specialized product development team.
The Unicorn Product Manager
In many cases and depending on company size, these PMs need to be so-called unicorns. I’ll explain why, along with a discussion of steps that me and the company took to address the situation and also make the product department more flexible and scalable.
Below is a diagram and description highlighting the core competencies that the company’s PMs initially needed to have (enclosed by the dotted orange line). They are product management, project management, client management, and account management. In addition, technical experience was a really great bonus, particularly if it included IoT.
It’s worth noting that technical PMs are less common, and are usually considered technical if they have expertise and actual experience in a technical field. A good example is a software engineer that pivoted to a PM role.
Let’s discuss these core competencies a bit further.
Product management expertise and skills include having a deep understanding of product management principles, techniques, and product development methodologies (e.g., kanban).
Project management, on the other hand, utilizes skills involving the iron triangle (the balanced equation between cost, schedule, and scope), risk management, resource management, milestones, etc.
Client management is all about identifying opportunities, effective communication, generating a shared vision and understanding, expectation management, relationship management, providing transparency and visibility into every aspect of delivery, and so on.
Account management is about keeping clients happy, creating SOWs (including initial budgets, scope, and timing) and getting them signed, working with accounting and legal teams as needed, acting as a point of contact, etc.
So to summarize in the context of many previous company projects, a great PM (i.e., unicorn) was someone that is a highly experienced, technical expert in product management, project management, client management, and account management. They have to devise transformative product visions, strategies, and oversee the successful discovery, development, and delivery of an end-to-end, enterprise-level, smart connected solution. In addition, they have to create and execute very complex, large scale, technical product roadmaps with advanced product development and analytics teams.
This includes owning development and delivery timing, tracking, and understanding across all work streams, which for typical connected smart projects are shown below.
Hardware and Connectivity
PCB Design and Rapid Prototyping
Mechanical + Industrial Design
RF Connectivity + Optimization
Bluetooth / LoRa / Sigfox / Zigbee / 6LoWPAN / Wi-Fi
Over-The-Air (OTA) Firmware Updates
Communications Protocol Design
Embedded Security + Encryption
User experience (UX)
User interface (UI) and visual
Software architecture, engineering, and data ingestion
Mobile, front end, back end, and full-stack engineering
Database engineering and administration
AWS / GCP / Azure / Losant / Particle IoT Platforms
MQTT / CoAP / HTTP
Cross-platform Mobile SDKs
Real-time + Batch data processing
DevOps and site reliability engineering
Non-functional requirements (scalability, availability, reliability, etc.)
Scaling both horizontally and vertically
DevOps and Infrastructure as code
Experimentation and analytics
User engagement tagging and tracking
Data science and advanced analytics
Descriptive, predictive, and prescriptive analytics
Commercialization and Testing
Design for Manufacturing
Test Plan Development
Production Line Testing
There you have it! That’s all that was required of the company’s PMs. There must be people like that who have this experience and expertise on every street corner. Right? If you’re shaking your head right now and wondering what the hell I’m talking about, you’re spot on. These people don’t exist, and if they do, they’re extremely rare.
So then how do you solve this unicorn problem? Also, how do you scale the product department as the company grows? The company more than doubled in size while I was there, during which time we definitely had to solve a lot of these challenges, and they will continue to do so as they grow.
Scaling a Unicorn Product Management Team
Until new product management team scaling strategies were developed, one person at the company was in charge of handling all of these aspects of a project, as shown in the diagram above. As you can imagine, it was very unlikely that one person had the experience, expertise, and even interest across all of it. Not only that, there wasn’t an entry point into the product management department without being a very senior or unicorn PM. What to do?
The first solution was to introduce a new role, the business analyst (BA). In this case, the PM would focus mostly on the product management, client management, and account management side of things. The BA would share product management responsibilities and also handle project management tasks. This is shown here with the orange line representing the PM and the gray line the BA.
As shown, and in terms of product and project management, the PM would focus on the product vision, strategy, and roadmapping, while the BA would focus on day-to-day roadmap execution, development, and delivery with the product development team. The PM would also own all client and account management.
The BA role at the company combines traditional BA responsibilities with those typically associated with a Scrum Master role, and also handles small amounts of project management tasks as well.
This was a definite improvement, and provided additional benefits to the company. By introducing a BA role, the company was able to:
Improve department scalability and growth
Improve department versatility, flexibility, and ability to dynamically fill gaps and provide coverage as needed
Provide employment opportunities for BAs of any level, and also those early in their careers that are pursuing an eventual product management role
Provide a clear and well-defined career path and opportunities for professional growth
Create a more collaborative product department that promotes knowledge transfer and shared learning
Provide opportunities for PMs to mentor BAs
Provide opportunities for PMs to possibly groom BAs for future product management roles, depending on the BA’s career goals and interests
Delineate between lower and higher cost roles, thus providing the ability to hire lower cost people to focus on tasks requiring less experience and expertise
Despite this tremendously helpful change, this still left a pretty sizable gap that we discuss next.
The Big Gap
At a services company, stakeholder relationships and management are different. Client projects involve master service agreements (MSAs), statements of work (SOWs), change requests, legalese, pre-defined scope, budgets, schedules, etc. Not only that, these projects require sales at every stage. Pre-sales, mid-development sales, and sometimes post-sales.
It also involves generating and presenting innovative proposals, understanding of complex organizational structures, and the ability to justify the value and cost of a project, possibly to a room full of C-level executives at a multi-billion dollar a year enterprise company. In addition, one must also be able to field any question, comment, or concern thrown at them on the fly. That’s not something that PMs from product companies are normally used to doing, or particularly want to do in some cases.
I’m not saying that a lot of the stakeholder collaboration and management isn’t the same between product and services companies, much of it certainly is. What I am saying, though, is that consultants are trained from day one to handle a lot of these responsibilities and have the skills just described. Also, PMs usually like the discipline of product management specifically, and are most interested in that and not necessarily in consulting and account management.
This results in a big gap, and still requires unicorn PMs despite the introduction of the BA role. So how does a company continue to be an extremely product-first, product-driven services company, without becoming your run of the mill behemoth consultancy like those that shall not be named? As the saying goes, “Nobody ever got fired for choosing IBM”. But I digress.
Although PMs have needed to handle account management and client management, a gap typically existed anyway for the reasons described. This gap is shown in the following diagram.
In some cases the gap is with client management instead of account management, but there is usually a gap somewhere. To fill this gap, one strategy developed was to introduce a new role as shown here.
In this case, the PM and BA responsibilities stay the same, with the only exception being that the PM no longer owns account management, and the client management aspect becomes centered entirely around traditional product management-esque stakeholder management, and less around client management as typically associated with consultants and consultancies.
This new role should be responsible for client and account management solely, and is expected to have a high level understanding of product management and product design principles and methodologies. This person is supported by the product management team’s product expertise where needed. This person should ultimately fill the consulting gap.
Product Team Scaling Through Roles and Leveling
A services business must be dynamic and nimble since things change regularly. Clients come and go, accounts shrink and grow, efforts must be placed into sales opportunities, and so on.
In addition, not every project and budget is the same. There’s a big difference between the scope, budget, and resources required to build a mobile app versus an end-to-end fully connected smart solution for a huge enterprise company. While the company focuses mostly on the latter, they also do some digital services work, particularly for long-term clients with which they have strong partner relationships.
As a result, the requirements in terms of roles and level (i.e., seniority) required differ on a client-by-client and project-by-project basis. Defining different product department roles as already discussed, and then hiring for each at varying levels (e.g., Jr., Mid, Sr.), allows for improved departmental versatility and ability to execute on the unique requirements and challenges of different projects as needed.
Is This a Product Challenge Only?
The question is, do these scaling and unicorn challenges only apply to product management and PMs? The answer is no.
The more that a single person is expected to have experience with, and be an expert on, the more they become a unicorn and are hard to find and hire. The more expensive they are as well. While we’ve discussed this in terms of PMs, the same is true of data scientists.
There is currently a major shortage of data scientists and advanced analytics professionals. The prototypical data scientist as an expert programmer, statistician and mathematician, effective communicator, and MBA-level business person is a uniquely difficult combination to find in any one person. The reality is that people are often good at some of these things and less at others.
As a result, roles have become more specialized. Now there are data analysts, data scientists, data engineers, machine learning engineers, AI engineers, and so on. In addition, some companies are replacing the single unicorn data scientist with a group of people that when working together are the ultimate powerhouse.
Take for an example an MBA working with a statistician working with a software engineer. These three individually are much easier to find and hire, and when working together get the same job done. The potential downsides are the increased salary costs, and additional costs associated with internal team communication and coordination.
Scaling and growth present challenges to any company, particularly to a services company that builds transformative, connected, smart solutions, which is no easy task.
These challenges are very interesting, have no easy solutions, and the companies that are able to successfully solve them while experiencing significant growth will certainly be at the front of the pack.
Illustrations by Dana Logalbo and Alex Castrounis
Originally published here.