As the product manager at Proximate, one of my most important roles is to serve as the mediator between our engineering team and business development. It’s a demanding job, keeping track of our developers’ ever-more-complex timeline while incorporating the real-time customer insights of our sales team. But someone has to do it.
“Uh, aren’t you guys three people right now?”
Well, yeah. On the surface of it, it should seem like our organization might not need a lot of active mediation. IBM we are not; when I say I serve as the go-between between engineering and biz dev, I’m talking to one full-time person in each “department.” But in my first six months on the job, I’ve started to discover a few truths that have helped me as a newly-minted product manager and might relate to others working on a small team.
You’re a PM because you’re average.
That is, you’re supposed to be the average of the teams you work with. As the PM, actively directing the development process and preparing for its payoff in successful sales, there’s no substitute – and no excuse – for not actively engaging in both sides of a startup’s life cycle. You have to make something and sell it, and be comfortable not having complete control over either side of the process, and with not being “the one in the spotlight” for either one.
Ultimately, you’re accountable for the results of the team, and particularly for making sure that any slip-ups don’t negatively impact the whole project. I’ve found that my mood at any given point is a pretty good barometer of how well we’re clicking as a team; if expectations are off on one side of the dev-sales equation or the other, it’s going to mean stress for me. (And that’s a good thing.)
Product needs take precedence – except when they don’t.
I’ve frequently seen the PM role described as “making sure sales stays out of the engineers’ way.” While we’re blessed to have an experienced sales lead with product experience, that friction between product and sales timelines can sometimes occur. At these early stages, it can happen often, given that the spec must be fluid as we actively work with paying customers to test out our hypotheses. (Steve Blank and Eric Ries must have known they were gonna make my life difficult.)
I’m finding that, when I have to mediate between the needs of making a particular sale and the need to keep the project on track as laid out, I side probably 80% of the time with my engineer and the existing pipeline. However, it’s often that 20% of the time – revamping a feature quickly to meet an important beta customer’s demands, for example – that moves the needle on revenue. Realizing that we don’t yet have a product that’s perfect for anybody, let alone everybody, and having the confidence to sell it on its current merits, is key to staying on our targets. The careful flexibility to recognize when the product needs that one more merit to sell is how we’ll grow beyond those targets.
Biz dev buys the pizza.
When you’re working with a small team, crisis moments mean it’s up to the PM to pull everyone together, regardless of their functional role. It’s in those moments, when you’re trying to focus and put out the present fire, that finding ways to involve all functional roles builds incredible cohesion, trust, and plain old joy in working together. As often as possible, sales and dev should know what each other are up to, by being there. Working with a startup really shines when you feel like you’re working on challenging problems with smart people you respect and enjoy, across the organization.
I’ll tell a short story to illustrate.
Late last year, we were working on our first big beta project, an expensive conference projected to sign up 500 attendees. Having tested the system to open for registration at 8am the next morning, the rest of the team shut off their computers and prepared to go home for some much-needed sleep. As I stayed behind to finish up some email, an automated warning hit my inbox at 10pm. Our PayPal account, working just a moment ago, was now non-functional and on administrative hold.
In a panic, I called PayPal and found that they had frozen our account to check if our service met their requirements. (This despite our having run the PayPal system for a month; never, EVER rely on PayPal.) The review would take weeks, and there was no way to keep the system running while they deliberated. Our website was effectively non-functional for the foreseeable future. After a few cathartic-but-useless choice words for various PayPal employees, I resigned myself to the reality that we’d just forfeited thousands of dollars in revenue and completely lost a customer. I prepared to call the organizers and apologize, but first went off to deliver the bad news to my team.
Thankfully, I was to meet the team and some friends next door at the bar before we went our separate ways. I slunk into my chair and broke the news our team. Our developer just refused to accept the reality, I thought – “Well **** it, we’re gonna rip out our payments system and rebuild it tonight to use Stripe.” (ALWAYS rely on Stripe.) We threw some money down on the table, left without our beers (the tragic part of the story), and ran back to work.
That night, our team of three stayed up until 5am and, with the help of two amazing dev friends, fashioned a new payments workflow from scratch. I can hardly call what I did “project management” – it was primarily directing panic – but everyone put aside their roles and did exactly what was needed. I’ll never forget “biz dev,” with no sales to make at 2am, running out for pizza and pop. I watched the whole team fell asleep on the floor an hour before registration opened; the Stripe logs tailing, successful charges on the monitor above their heads.
A three person startup. It’s no Microsoft, but for me it’s a lot to manage.
And I wouldn’t trade it for any job in the world.