How I discovered I’m a product manager
When people used to ask me what I do, I’d spit back a well-rehearsed, energetic elevator pitch about my current project: the team, our software stack, and the fast-growing market my company was addressing. On a good day, I’d be met with a confused “oh… interesting…” Maybe a follow up question or two. On a bad day, all I’d get was a blank stare. One time a guy just kicked me in the shins and ran away.
Today, I tell people I’m a product manager. And honestly, the responses I get aren’t too different. Most people don’t really know what product management is. In fact, most self-proclaimed product managers don’t even agree on what they do. I’ve been interviewing PMs for my team at Postlight recently, and their descriptions of their daily activities fall anywhere from database administrator to digital marketer to executive assistant to lion tamer.
For the past 3 years I’ve worked at the intersection of two industries rarely mentioned in the same breath: software development and electronic dance music (you hip, young readers might know the latter as “EDM”). In 2013, I co-founded a startup called hostess.fm. You can tell by the dead URL that I’m super good at startups. We built software that helped DJs broadcast live music on the web. It wasn’t your typical social networking, peer-to-peer lending, ride sharing, snapchatting for millennials seeking millennials app. But we faced many of the same challenges most startups do. And, like most early-stage founders, I had a few key responsibilities on my plate:
- Figure out what to build
- Convince people it could make money
- Find designers and software developers to build it
- Make sure they built it right
- Convince users (DJs in this case) to use it
I spent most of my days working on our product with the designers and developers on my team. I wasn’t exactly an expert, but I figured I could pick up the essentials along the way. I reviewed lines of code, read about new front-end frameworks, and conducted interviews. I talked about mobile optimized typefaces, Google’s material design spec, and points of friction in our user acquisition funnel. I gave lots of feedback. When people asked me how our platform worked, I’d rattle off acronyms from the Amazon Web Services product catalog. I think we used some of them. I made pitch decks that summarized what we’d done and where we were going. I made Google Docs with dates and deliverables. I changed email signatures compulsively. I couldn’t decide which was more impressive: the minimalist, title-indifferent, first-name-only approach, or the verbose life story with a legal disclaimer about how nothing I had written could ever be repeated to anyone under any circumstances ever.
I spent my nights with small-time DJs at local nightclubs. I struggled through redbull vodkas, asked the DJs about their equipment, and bobbed my head endlessly to deep house beats. I talked to DJs about their workflow and their audience, helped them use our software, debugged issues, and stuck around through the night to make sure things went well. In the morning, I’d report back to the team on what I’d learned and ideas on what we should build next.
By 2014, we had cobbled together a working website and iOS app, grown our team to about 10 people, and streamed a few thousand hours of live music. Only about 1% of it was played by DJs people had actually heard of, but the other 99% made for great graphs on my pitch decks. I sold my startup to SFX Entertainment, the world’s biggest producer of electronic music events, and I joined their product and technology team, called Beatport. That was the first time anyone put a label on what I was doing; they called me a product manager. My first week on the job, I asked my boss what that meant. He told me to keep doing what I was doing.
We rebuilt and rebranded, and a few months later launched Beatport Live, a product that’s since streamed massive EDM festivals like Tomorrowland, Electric Zoo, and Sensation White to millions of fans around the world. Suddenly, we were operating on a very different scale than we had been at hostess.fm. And yet, my responsibilities really hadn’t changed. I still worked closely with the designers and developers on my team, though the software was more complex and the user experience more refined. I still schmoozed with small time DJs, but now big ones, too. I sat in festival production trailers full of cameras, cables, and trendy Dutch guys. I studied Audio/Video encoding applications, and even led a small team to build our own. I worked with a social media team to grow our audience, business intelligence to understand our users, and ad sales to increase revenue. We watched, learned, iterated, and at some point the whole thing didn’t feel so cobbled together anymore.
A few months ago, I left Beatport to help start Postlight, a product development agency in New York City. When we started the company I took on the role of Director of Product Management, which means I lead a team of PMs who work on various products for our clients. This new role has required me to reflect a bit on my experience as a PM, how I define the position, and what I’m looking for in the PMs I hope to add to my team. As it turns out, my responsibilities at hostess.fm provide a good framework for thinking about what a PM should do:
1. Figure out what to build means…
Identify a problem, talk to affected users, experiment with existing products and workarounds, brainstorm potential solutions, and define a minimum viable product that addresses your users’ needs.
2. Convince people it could make money means…
Sketch or prototype your product, estimate development timeframe and costs, identify potential revenue streams, outline a viable business model, solicit buy-in from key stakeholders, set clear expectations, and define KPIs to measure your product’s success.
3. Find designers and software developers to build it means…
Conduct interviews, assess talent, build a team, and help motivate and lead that team to develop the product you’ve agreed upon.
4. Make sure they build it right means…
Manage the daily product development process, facilitate communication, give feedback, be familiar with modern design and development practices, apply project management methodologies as needed, communicate changes in the roadmap to stakeholders, and be held accountable whether things go right or wrong.
5. Convince users to use it means…
Define a rollout strategy, A/B test product features, craft a marketing plan, manage an analytics dashboards to see what works and what doesn’t, and implement a support system to help users when things don’t work as expected.
6. Repeat means…
Understand that a product is never done - that it is a living, breathing thing that should constantly be adapting to incorporate feedback, to better serve its users, to address changes in the market, and to capture new opportunities as they emerge.
It’s taken me a few years to get here, but the steps above articulate what I generally believe to be the role of a product manager. It’s not an exact science, and often times this list won’t map directly to the daily activity of a PM. Above all else, a PM has to keep things moving forward, even if that means deviating from this set of core responsibilities. But this framework helps me approach and decompose new challenges and structure the work in front of me.
If any or all of the above describes what you do, then congratulations! You might be a product manager, too. I hope this post helps you explain your job next time someone asks you what you do. But don’t expect much more than a confused “oh… interesting…”
How do you define product management? Comment below with your thoughts or ping me on Twitter @_tydalwave_.