“So, you’re gonna be working with our 4 offices spread accross all time zones and your development team is located in Polynesia, but ya, you gotta come in to the office from 9–5 everyday.” Photo by JESHOOTS.COM on Unsplash
As the tech industry and its projects become increasingly fast-paced, the need for “scalable” talent mounts.
In some areas, it has become somewhat common to work with outside contributors and contractors, be it a freelance designer, a contract development team, or an external consultancy, while other professions remain mentally “ingrained” in the core organization, as a full-time, employed, on-site position — just like product management.
Don’t have all that time to read the rest? Here are the TL;DR Key Takeaways:
- Making room for freelancers in your Product org should be your goal — being able to quickly & easily scale your org gives you quite an edge over those rat racers exclusively hiring for employed product managers (or have fun planning 4-6 months in advance for when you’d like to onboard a new product manager!).
- Don’t fall for the ‘compounded knowledge’ trap — your on-staff people don’t just get better at what they do purely based on elapsed time (I’d argue that at some point, they’re getting worse) and bring in an external set of eyeswhen you feel like a project setup might be stuck. You might be surprised that some answers might have been in front of you the whole time — or that they needed an independent voice to say them.
- Don’t burn out your product managers! Just don’t. Get them some help & support — you’ll save both money and good team members in the long run.
Still here? Alright, let’s go:
It starts with understanding what product managers *do*
Whenever I’ve encountered someone requesting product management services that’s hellbent on getting a full-time, on-site employee, the question of why is usually answered with a lofty reasoning along the lines of
- “we want a strategic stronghold in our core team” (which is usually a lie because they’re not willing to pay the kind of money it takes to get someone who’d actually be able to deliver on that), and/or
- “we need someone reliably available to tackle all the product challenges we’ll have” (which is usually code for “we have no idea what “product” is, and for the lack of better knowledge, we’d like to throw a body at that & hope that somehow works).
Now, regardless of whether they’re looking for a full-time job or freelance opportunities, this might raise a red flag to talent — it strongly suggests that you have no idea what to expect from a product manager, and the process of learning that on your agenda is mostly trial and error, the brunt of which that product manager will need to bear.
I mean, I get it — usually it’s hard to anticipate what a product manager needs to do if there isn’t a sophisticated and established modus operandi in place.
But I’m not talking about the exact count of stakeholders a product manager needs to keep in touch with, a specific business & product roadmap or even which tool to use for organizing work — having all these (somewhat) figured out is great, but there’s a much bigger problem lying underneath:
“Undefined” quickly turns into “too much”
As I mentioned, it’s okay to figure some stuff out later/along the way — which is one part of being agile that is less loved by organization reps.
But: what is the (perceived) benefit of not specifying work to be done?
- To product managers, if at all, the benefit might be less overhead with tracking work.
- To companies/line managers, it’s the (perceived) “open tab” of work — if responsibility for quantifying (too much) work is diverted to the product manager, the product manager’s also made responsible to raise (and back up) being overburdened.
I’ve seen quite a few people getting burned out that way. And setting aside the damage done to a human, this means you’ll need to look for a new product manager, at least for the foreseeable future.
What then?
Contrary to common perception, Product Management work isn’t that hard to measure or quantify.
I’d even go further and allege that not doing so under the guise of “keeping it simple” and “staying able to swiftly react to things as they occur” will ultimately be the product manager’s bane when suddenly realizing they’ve got too many balls in the air, just before they’re about to drop them all.
Now, bringing in freelance talent isn’t the only way to do proper resource planning, of course — but can compliment you well in elevating your Product organization’s success to new levels.
Bringing in Freelance Talent
Let’s be real — for some things, you can (fairly) safely assume that you’re going to need someone on end for it, like core business applications or popular products with a firm foothold in a rather consolidated market.
But sometimes, you e.g. wanna do something like a redesign — and while your core team is working on the existing version, you’re gonna need extra hands to build the new version, then hand it off to the core team — and then? Those folks may leave after.
Or — you’re looking to run a project for which you have sufficient internal resources for delivery, but as you’re moving forward, you’re noticing that the project is falling victim to “organization fatigue” (“We’ve always done it that way”), and instead of focusing enough on actually solving the problem, people are moving into a mode of “complain and concede”, in which they disheartenedly take the path of least resistance. So you might need an “outside influence”?
Or — you’re looking to do an exploratory project, and it has a fixed time scope. Would you rather stretch & burn out your on-staff people that are most probably busy enough already, or get people specifically for that project?
Or — it can be something as mundane-seeming as one of your on-staff people heading out on a prolonged parental leave of absence.
In any case — wouldn’t it be great if you knew at least a few people that you’d be able to call up & bring in? Exactly, which is a good argument to ideally have a handful of freelance PMs on file that you can call when you’re in need of support.
Interim Managers: Tapping in & out
Instead of abandoning a topic when someone’s off for a longer while (more than ~4 weeks), or overburdening someone else with it, you can bring in an interim product manager to bridge the gap.
They can usually onboard into a productive mode within 1–3 weeks (depending on complexity) — much faster than permanent staff because they don’t need to get to know everyone and everything. Dealing with multiple clients per year (and sometimes simultaneously), freelancers are much more routined in what they need to know and do — and what what they don’t.
Fully aware of eventually leaving again, they also usually realize that continually keeping and leaving proper documentation and reporting of their work is elemental to reduce “brain drain” — something I’ve very rarely observed with permanent staff.
Consultants: Eyes for your blind spots
If you’re faced with a more integral challenge, like a rather junior Product staff and/or immature organizational processes, it’s generally a good idea to bring in a second opinion.
I mean — doctors do it, big firms do it (for audits), even creatives like music and film producers bring in multiple people for different tasks to get synergy out of collaboration, even if technically less people could also complete the task at hand. Even developers do this, sorta — it’s called pair programming & peer code review.
So, why would this be profoundly different in Product Management?
If there’s anything product managers and doctors have in common, it’s that both have to make a lot of decisions, usually without sufficient time or information, and bear the consequences of those decisions.
But instead of accepting the reality of just not being able to get it right every time, product managers are told to “obsess” about things more, in a pursuit of becoming the ultimate domain expert. However, all that’s going to make them in the long run is less adaptable to change.
So yeah, consulting should be bigger within Product Management in general. You can also establish a sort of “peer consulting” within your staff. More prone to bias, but it would be a start. If you’re seeing internal bias as a major issue though, it might be high time to bring in someone unburdened by the organization’s social construct.
So, how about it?
What’s your stance on how you (want to) run and scale your product organization? Do you believe that product management could use more consulting, or do you disagree entirely? Have you burned out a staff member, or yourself? We’d love to hear from you, please leave us a comment below!👇
Interested in more stories around freelancing in Product Management? We publish regularly to our Freelance Product Manager publication & would appreciate a follow! 👆
And as always,
Thanks so much for reading!
We acknowledge that with the 7 minutes, you could’ve literally done anything else, and we’re very honored that you decided to dedicate them to our piece! ❤️
Pingback: A Cost-Conscious Case For Hiring Freelance Product Managers - Freelance Product Manager