Many start up Product Managers are lone wolf types. They work alone, part of a team, but the only one in that team doing what they do. Shuttling between engineering, design, sales, marketing, management and other constituents, they are the glue that ties the team together, the universal joint making sure all the momentum in one group transmits cleanly to the next so all the pieces move in unison and things get done.
Because they work alone, Product Managers have developed their own set of tools that work for them and their company. Tips and tricks on how to organize teams and set priorities are passed around like folklore on blogs and Quora posts but it’s rare to find an event that gets a room full of PMs sharing what works in real-time.
Perhaps it’s a sign of a maturing industry legitimizing a role but over the past several weeks, I have had the good fortune to attend three (!) events specifically for the modern Product Managers.
Each of these events were great in their own right but it was this past Friday’s How to Build Great Products hosted by Ty Ahmad-Taylor of Samsung and Josh Elman of Greylock Partners really knocked it out of the park.
What I Learned
Many PMs fell into their role before they realized that they were doing it. Especially at small start ups on a hyper growth trajectory, the PM is the first to jump in to rally and organize and bring teams together and ends up creating their job.
PMs need to have a singular focus on what needs to get done to make their product successful. This means sometimes going against corporate objectives. Hunter Walk, when he was a PM at YouTube, put priority on supporting Facebook login over Google’s own competitive Open Social login initiative. You need to look at the market as a consumer and make the choice based on what’s right for the customer, even if it sometimes goes against larger corporate initiatives.
PMs need to be entrepreneurs. Faced with a limited amount of resources, you need do whatever it takes to get things done. This often means you need to think creatively. Hunter also mentioned “learning to draft ascending ecosystems” – take an objective look at the market and if there is a way for you to bundle or integrate your product into another product on the rise. By focusing on getting the YouTube icon added to the default iPhone deck, all other conversations with carriers turned from YouTube chasing them to the carriers calling YouTube. Picking the ascending leader early was a bet that paid off.
Trust Your Strategy. Allen Blue, the co-founder of LinkedIn, described the first year of nominal growth (2,100 users after one week, 80,000 after 7 months). They reserved a bottle of whiskey for when they hit 1 million users but ended up drinking at 500,000.
PMs are problem solvers, give them meaty problems to chew on. Like Allen, many PMs come from varied backgrounds. Allen came from the theatre. Because of their non-traditional training (Hunter Walk too, was one of the few PMs at Google without a CS degree), a PMs can be the source of a unique perspective and often solution. One useful technique to use when drilling down to the essence of a problem is by using the 5 Hows which is a derivative of the 5 Whys, designed to lead you to a solution, not causality.
Srikanth Rajagopalan on building the Chrome Browser
“Speed is a feature.” This is often ignored when prioritizing tasks. Do not forget that simplicity, and it’s cousin, speed, are silent feature requests that should always be potentials for any roadmap discussion.
Build for the average user but do not ignore your super fans by hiding power user features. Chrome has a number of geeky features (Keyboard shortcuts that one could only appreciate if you, “grew up with vi”) but they are tucked away and do not get in the way of the basic user’s core experience. Deciding how to add an advanced feature is difficult. Putting it into Settings and letting the user choose is lazy. Did you know Chrome has a detailed Site Info box?
There was a panel discussion about user growth where I unfortunately had to step out for a bit but I did catch Elliot Shmukler talk about the power of shared metrics. During his days at LinkedIn, he pulled together the most important metrics into an information radiator so that everyone gets a realtime view of these metrics with just a glance. But one must not forget to focus on the right metrics. Too often a dashboard is swamped with metrics where it’s too easy to drown in data. Pick 3-5 metrics and use those to test intuition. Be careful which metrics you chose because those will be the ones you optimize for.
A funny anecdote Elliot shared was coming in one morning to find, “Belgium on fire.” User acquisition spiked overnight because an engineer, after looking at these shared metrics, fiddled with some of the contact importing settings for users in that country to see if it would move the needle. It did. That is the power of shared metrics.
Dan Olsen gave an entertaining talk about his time at Friendster during their meltdown and subsequent loss to MySpace. See slide 21 which shows how he came up with the concept of the viral loop (no one was doing this kind of stuff then) and how different points in that loop have different amplification values.
Despite succeeding in rolling out several new features that helped in user growth, we all know the story about poor database optimization that ultimately ruined the experience on Friendster so that the more users joined, the slower the site became. Dan’s learnings were that, for social networks, a large user base is a feature. People used MySpace because that was where the majority of their friends were which lead to, um, a majority of their friends being on MySpace.
Fred Sigman, an Art Historian & Photographer, gave an thoughtful talk about the influence of nearby atomic bomb testing on the neon signs of early Las Vegas. As a post-lunch talk, professor Sigman’s talk was perfect as the, “palette cleanser” talk before we got to the. . .
Ignite talks. These are lightning round, Pechakucha-style presentations where the slides self-advance. Highlights for me were Ken Norton’s How (not) to work with Engineers and Ian McAllister’s talk about the User-Driven Development which I’ve written about before.
Joe Zadeh from AirBnB spoke about the hiring process at his company. Forgive the fuzzy resolution but it’s the nut of his talk which explained that all PMs that are interviewed are invited in to present on a topic given to candidates in advance. This allows them to evaluate all the candidate along a baseline for a number of things simultaneously,
- Can they communicate effectively?
- What’s their design skill like? Do they understand spacing, fonts, color, use of graphics?
- Are they nervous presenting? How do they respond to questions, pressure?
- Did they have a fresh approach? Are they an original thinker?
If the interview is for a Product Manager, they may make it about a specific problem they are trying to solve. When they were looking into adding a payments processor in South America, they asked prospects to speak that topic. By the end of the interviews, they had not only a good sense of who knew what, they also got six different approaches to integrating payments processors.
James Buckhouse from Twitter gave an great talk about storytelling. @buckhouse came from Dreamworks and tells stories for twitter and shared his formula for how to tell a good story. It’s all about the journey to a transformation. He writes about writing on Medium at Design Story.
The final talk of the day was with Tom Conrad at Pandora. No slides, just a simple discussion between Josh Elman and Tom about the early days of Pandora and it’s inspiration (“I loved to recommend music to people. Building a service was a lot easier than inviting people to my dorm room.”) but also included a varient of the “let’s go shopping” style of roadmap prioritization.
- Every 90 days, wipe your roadmap clean.
- Ask everyone in the company what things the company would be crazy not to do. This includes projects that used to be on the roadmap but are now off it.
- Summarize each idea on one slide. Work with engineering to come up with a thumbnail estimate for how many days it’ll take for each project. If a project will take one weeks’ development by two developers, that’s a $10 project.
- Print out each slide and stick them up on a wall.
- Sit with Engineering and decide how many developer man-days you have for the next 90 days. If it’s 60 working days and you have 2 developers, and you need to reserve 10 days for maintenance, that means you have 110 developer man-days. This would equal $120.
- Invite a cross-representative group of people to a product prioritization meeting. At Pandora, this included someone from HR. Give each person a different colored post-it note with equal amounts that they can allocate towards projects. If there are 5 people in the room, then that’s $24 each.
- It will be a long meeting but, by the end, you’ll clearly see which projects are “fully funded” and those will be the ones that you take on for the next 90 days.
Everyone leaving that room will have a clear view of what engineering is going to be working on better than any Roadmap document could tell them. There will be no need to brief people on what each project is because they will have heard the description of each project in that meeting.
I hope you found this post useful. I’m gathering these tips and tricks into a collection. If there are some that you feel should be included, let me know.
