What a treat! Dan Olsen just finished sharing his thoughts at the SF StartUP Product Talks on best practices for being a product manager and living product management in a startup environment.
Product Management Best Practice
Who is Dan Olsen?
I found this fascinating as I’ve been asking folks in SF how they arrived at their current state in life – amazing to hear the various stories and this one is no different. Dan kicked off professional life as an engineer in the navy conducting submarine design. That got him a Masters in Industrial Engineering, paid by the navy, nice! He then headed to the Stanford Business School to get an MBA. He followed this up with a five year stint at Intuit as a product manager which gave him experience in product management and marketing.
Dan then moved on to his next gig at consumer play Friendster. After that he decided to teach himself PHP, MySQL, etc. He moved on to consulting (business cycles…) and was Interim VP for a few post-Series A startups.
Of course like most folks at SF StartUP Product Talks Dan wanted to do it himself. So he kicked off and bootstrapped YourVersion which is like a precursor to Flipboard (it his the TechCrunch 50 in 2009). YourVersion got seed funding although didn’t see the hockey stick growth that consumer apps need.
Boom!
What is a Product Manager?
Many different titles for very similar roles – Product Marketing Manager, Program Manager, Project Manager, etc. See Rich Mironov’s May 2012 SF StartUP ProductTalk for more on this.
The best way to think of Product Management is as an area of responsibility versus an actual position.
The Product Manager sits between the market (customers) and the development team.
A successful product manager has a successful product. They may think of themselves as a Mini GM or Mini CEO.
Common refrain of all this product management talk – Little responsibility, no authority. It is an influencing job.
With great power comes great power.
With great responsibility comes no power.
What does Lean mean?
Think of the intersection of The Lean Startup and Product Management. As a product manager you are trying to find product / market fit – when the customers like what you deliver.
Being Lean means you clearly articulate the hypothesis then test and learn. Eric Ries calls this the Build, Measure, Learn cycle. More on The Lean Startup next week when I post my conversation piece with Eric Ries from Atlassian Summit 2012.
Problem Space vs Solution Space
Some startups may code things as they are just plain cool. They are building a solution without necessarily identifying a customer problem first. When you are really clear on the problem space it will help identify a solution, it will also help identify any competitors.
Question from the audience: Isn’t it true that in the real world a founder may have had a cleaver idea and their solution in search of a problem can hit it right?
Dan responds with:
Perhaps, but I would think they did a good job understanding the needs of the customer. People, media gloss over that aspect and just focus on the winners (not the many that didn’t make it). Alternatively the founder is scratching their own itch, as they know that it is their problem and they are building a solution to it.
Dan uses the analogy of a submarine with a homing torpedo – as long as you get it in the right product vector you can listen and respond to customers. Same with a product, if a founder with a strong product vision launches something that is kind of in the vicinity of the customer problem they can then respond to customer feedback and hone in.
Question from the audience: Can you create a pain point where there wasn’t one already?
Dan responds with:
Can you turn a vitamin into a pain killer? This is called anchoring – people have a perception and you can educate the market.
How does one assess customer value?
As product managers we want to order or prioritise benefits and features based on customer value. One pattern you see in different frameworks is importance vs satisfaction – importance of user need vs satisfaction with how the product meets that need.
One framework that focuses on importance vs satisfaction is the Kano model. The Kano Model talks about
- Performance (more is better)
- Must Have (table stakes)
- Delighter (wow)
Things that used to be delighters (GPS in a car, for instance) migrate down to must have over time.
You can also assess your competitors using the Kano model and use their placement on the model to identify where you want to compete.
Survey your customers with existing features to learn where you should focus energy (development effort). Conduct an assessment of the existing product to identify opportunities for improvement in the next release. One thing that wasn’t mentioned here in the talk was Innovation Games.
Once you have all this information it leads to your value proposition:
- how are you better than competitors?
- which user benefits are you providing?
If you can’t answer this, then why would the customer buy your product?
How does one validate ideas with customers?
Building wireframes and/or mockups is a great way to validate your ideas, features and value proposition. This sounds very similar to the Build, Measure, Learn loop from The Lean Startup
Customers can not articulate the problem space – however, customers can react to the solution space. Use a wireframe / mockup for validation of the solution space hypothesis.
- wireframe – low to medium fidelity, greyscale, not pixel perfect
- mockups – high fidelity, fonts, colours, etc
- prototype – not actual product, to be thrown away, interactive
For product managers that want to get into wireframing you should look at Balsamiq (see recommended reading below). You should be able to take it to a point and then hand off to a designer.
There is no need to go the whole way to high fidelity. Good startup teams can go from whiteboard to implementation.
How do you bridge the gulf from Problem space to solution space?
The product manager should own solution space thinking. In some startups there isn’t anybody to be a product manager so the engineer has to figure it out.
Ideally you have product manager, designer and engineer.
How do we learn from customers?
As product managers we want to obtain feedback on UI design, UX, messaging, the feature set and more. Here are some thoughts:
Dan calls this approach the “Ramen” User Feedback for Startups:
- Anyone can do it.
- Have the solution space for the product or a mockup to test
- 1 customer, get them to bring their laptop (so they know how to use it and they are not distracted by a new machine)
- 1 desk
- 1 person to conduct the session
- pen and paper
- optional note-taker and observers
If you’re doing usability testing make the engineers attend in person, don’t just record it and let them watch later.
Typical format for Customer Session
- 5 – 10 mins: ask questions to understand user needs and their current solutions and workarounds
- 30 – 50 mins: user feedback, show the user the product/mockup, non-directed questions
- 5 – 10 mins: answer questions, point out explain features, ask them if they would use it
Explain to the user that their feedback will help the product, explain to them by saying ” we want to get your feedback so the more honest you are the better”. If they are reserved and don’t express themselves very well say “as your thinking of things just say what you are doing it as you do it” to get them to explain as they walkthrough the test.
Be a fly on the wall, let them do what they would do at home, don’t guide them through it. For instance, don’t say “that was easy, wasn’t it?”.
Don’t help or explain the UI – may be painful to watch, be patient and watch. Finally, don’t get defensive or blame the user.
If you are conducting a Private Beta then a usability test is the price of admission – you must come to usability testing to get in on the private beta.
An alternative is to conduct “Starbucks Testing”. Rock up at Starbucks and ask for a persons time in exchange for a gift card. Take a landing page (paper), put it down for five seconds and take it away – “now, what do you remember from that page?”.
– Reach out to people that help the people who you are trying to reach (i.e., suppliers for local businesses).
When do you have enough feedback?
You’ll see patterns.
Use metrics such as NPS or a conversion rate. From Eric Ries: “don’t use vanity metrics”.
Again, optimise through iteration. Build Measure Learn.
Job Hunt
It is important to note that different companies use different terms for this role, as we said at the start it is an area of responsibility rather a position. When looking for a job you don’t need to focus only on those with a “Product Management” title.
Bigger companies usually divide product management into inbound (Product Manager) and outbound (Product Marketing Manager). Some will also add Product Owners or Technical Product Managers to address the more tactical aspects such as building and ordering the backlog (in essence owning the backlog in an agile project management tool like GreenHopper). Further, in larger companies you will likely also see a VP of Product Management on the executive team.
In smaller companies or startups there will ordinarily be one person that wears all of these hats, and no doubt many more.
If you are unable to wireframe learn how. Dan says:
Product Managers should be able to wireframe – it helps move the progress along from problem space to solution space, towards a real product.
Further, when looking for a job in Product Management Think about your own Kano model:
- the Must Have’s now include being able to wireframe or mockup
- the Delighter may be the ability to actually code a prototype
Recommended Reading
- What Customers Want – Anthony Ulwick
(Dan’s best PM book, one we read at the Atlassian product management book club)
- Dapp for prototyping – $10, create the product on the iPhone (Dan uses this)
- Balsamiq (Dan recommends with “best $79 you’ll ever spend”)
- How to be a product metrics Jedi, another talk by Dan Olsen
- The Lean Startup
