A common challenge that Product Managers face is trying to move their product and company forward with limited development and testing resources. And it often takes a combination of skill, talent, and luck on the part of a Product Manager to pry additional resources from the limited pool that their company has to build and innovate on their products. There are, however, several things that a good Product Manager can do that will increase the likelihood of seeing the right type and amount of resources dedicated to furthering their goals, while mitigating the negative effects on other efforts across the organization.
“If you don’t ask, you don’t get.”– Stevie Wonder
Enter the Matrix: Know Who Makes the Decisions
The most important thing that any Product Manager simply must do when taking on resourcing decisions is to dive in deeply and to understand how the company goes about deciding which teams and what individuals work on which projects. In some large organizations, these are “matrixed” pools of talent which are common across the organization with teams spun up and wound down as projects gain in priority or are completed (or shut down!). In other organizations, teams have very specific areas of expertise or focus which drive their structure and assignment – there may be infrastructure, backend, API, UX, and/or integration teams which work together (or separately, in less-functional organizations) to bring about full end-to-end solutions. No matter which form your development teams take, understanding how they’re structured is the first step toward building out your request for extra talent.
No matter how your organization is structured, though – there is usually a person (or group of people) who makes the resourcing decisions for the teams. This might be a development manager, a director-level role, or even the Chief Technology Officer of the organization. Whoever makes those decisions, the next step in your process of asking for additional help is to figure out who’s going to make the call at the end of the day, and then to assess the relationship that you have with that person or group.
I’m a firm believer that building trust and respect is fundamental to being an effective Product Manager – because we lead through influence and not direction, it’s the biggest key that we have to open up the various locks that we may be presented with in our organizations. It’s not, however, something that just happens magically; it takes time and effort, so any good Product Manager should already have spent time building strong relationships with the key decision-makers. If you haven’t, you’ve got some pre-work to do before you “buy” the ability to ask for more resources.
“Dig your well before you’re thirsty.” – Seth Godin
Build Your Foundation: Collect the Data
So, now that we know who makes the resourcing decisions in the organization and how strong and influential our relationship with those people are, we can start to build the foundation for our request. As the great Jim Barksdale has said, “If we have data, let’s look at data. If all we have are opinions, let’s go with mine.” We need to either play to the emotions of those who are in authority – drive them to share our opinions — or we need to create a roadmap through the use of objective and subjective data to drive the decision. I’ll take data over opinions and emotions any day of the week, and twice on Sunday – and so will most people in a position of authority. Don’t risk the whims of someone else sinking your request; do your homework and collect the data.
But it’s really not enough to just collect the data. Anyone who’s spent 30 minutes looking at slide decks that never bring the data to a conclusion knows that raw data, while interesting, ultimately puts people to sleep.
Raw data is the first step toward building your foundation; putting that data into a form and format that makes it tell a story is the next. And this is where the art of Product Management comes into play – taking the data that we have collected and creating a narrative that’s not only supported by the data, but which leads inexorably to the conclusion that you want your audience to reach. When properly pieced together, your pitch needs to be unassailable. All of the data needs to point in one direction, and one direction only. Any opportunity for divergence leads to an increased possibility that your requests go in a direction you did not anticipate. Just like a good lawyer never asks a question that they don’t know the answer to, a good Product Manager never creates a presentation that has any end result outside their intended outcome.
“A point of view can be a dangerous luxury when substituted for insight and understanding.” – Marshall McLuhan
Make Your Case for More Product Development Resources
Awesome! Now we know who we need to convince, what we need to convince them of, and how we’re going to convince them. The natural instinct in most organizations is to call a meeting, get everyone in a room without context or prep, and to present your slide deck hoping that everyone agrees with your proposal.
No. That way lies failure and heartbreak.
Remember, everyone in your organization has different interests and agendas driving their decisions; even when teams are ostensibly directed toward the same goals, the nature of the variety of roles, jobs, and compensation packages that exist drive people toward different paths and different strategies. And this doesn’t even take into account the nature of many people to be highly self-interested – if we go blindly into a meeting with a large group of people, we’re taking on a Herculean task of balancing egos, interests, agendas, grudges, and all of the other social, political, and cultural factors that can alter how people make their decisions.
That’s just too many variables – remember, when we go into that meeting, we want the outcome to be known and predictable, which means that we need to manage for all of these variables before we go into that room and fire up the projector.
Savvy Product Managers know that pre-meetings are always more important than the actual meetings. You should plan on meeting with every stakeholder who can influence the decision before you bring the team together. You should already know the opinion and end state that each of those people want to see before the meeting request is even sent out. The key here is to have an in-depth discussion of what you need with each decision maker early on, so that you know how to tweak your presentation, polish your data, and modify your pitch so that as many people in the room are already on the same page. It also gives you opportunities to build trust and respect with these people, as well as to “fail fast” on your request in private if it turns out that you actually can’t bring people from zero to hero like you thought you could.
A good Product Manager never holds a meeting where they don’t know the most likely outcome. We don’t gamble on the vagaries of organization politics — we pitch a case that’s likely to win, or we don’t pitch it at all.
“Working with limited resources is an excellent way to hone skills that will serve you well for the rest of your career.”– Jon Oringer
Have a Fallback Plan
In many organizations, resources are tightly constrained and already allocated for any reasonable amount of time from today into the future. There are very few situations in which there’s a pool of developers or testers just sitting around, waiting for the next project to jump into. And it can be insanely difficult in many organizations to obtain a shift in resource and talent assignment barring the most explosive and financially guaranteed pivot known to man.
Knowing this, every Product Manager who’s making a pitch for additional resources must have a backup plan in place, so that if those resources don’t come through we can still make progress against our own and our company’s objectives. Often, this means taking a long, hard look at your project and reassessing the MVP that you’re trying to bring to market, or figuring out a strategy to incrementally build out the result that you’re trying to achieve. Sometimes it means cutting features or narrowing your target market, with the associated costs both future and present.
We have to remember that, to paraphrase Donald Rumsfeld, we often have to go to market with the developers we have and not the developers that we might want. It’s important to try, to ask, and to create your plan – but equally important to understand what you’ll do without those extra resources.
“Plan for the best; prepare for the worst.” – Anon