Archives For Product Management

Dan Olsen on Best Practices in Startup Product Management – SF StartUP Product Talks, June 2012

June 15, 2012

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

Appreciate the notes? Please

In Events, Product Management ,
 permalink

Business Model Generation with Canvas

June 3, 2012

While enjoying a drink with Martin and Roberto of Comalatech on Friday night – after Atlassian Summit had wrapped – I learned about their new Confluence plugin Ad hoc canvas. I didn’t really get it until Martin sent me a recent blog on the product – Business Frameworks with Ad hoc Canvas. What struck me as cool was the example of using it for Business Model Generation, a practice that we conduct in the product management team at Atlassian.

Very cool.

Using Ad hoc Canvas by Atlassian Expert Comalatech for a Business Model Generation exercise

References

In Product Management
 permalink

Rich Mironov @ SF StartUP Product Talks May 16, 2012

May 17, 2012

Rich Mironov led the discussion at the most recent SF StartUP ProductTalks. My introduction to product management was Rich’s book The Art of Product Management, so it was great to see him talk!

A huge thanks goes out to Rich for speaking and curating the discussion.

Below are my notes from Rich’s talk and the discussion. It was also interesting to see the folks looking for work and those who had open positions in their companies, although as Rich said – “you’re all looking for unicorns”, as in we are all looking for very particular people for our jobs and not filling roles with the available people when they are more than competent. That was an interesting takeaway for me.

On to the discussion notes:

@richmironov

To get things started Rich asked the attendees for some topics they wanted to learn more about, the results were:

  •  Product Owner vs Product Manager (16 votes)
  • Technical Skillset (15)
  • Working with Developers (8)
  • How to transition from project management to product management? (7)
  • Certifications (2)

What does a product manager do? (Slide deck)

(Slide 2)

Product Managers sit between three groups that don’t talk together, sit together, or have a common language. Executives, Marketing & Sales / Markets & Customers, Development

Development

  • PM Input – business requirements, guidance, market information, priorities, user stories, personas
  • Dev Output – software
  • If you are in development you are often blind to the interactions that PM has with the rest of the organisation.

Marketing/Sales & Market/Customers

  • PM Input: segmentation, pricing, demos; output: feedback
  • sales and marketing communicates what the customers provide

If you poll sales people:

  • why we win sales: awesome salespeople
  • why we lose sales: product sucks, too expensive, not enough collateral

Sales people have a ‘stack depth’ of one – they only remember what the customer asked for in the last meeting.

As PM people we need to talk to customers/prospects directly.

Executives

  • PM Input – market models, strategy, forecasts, etc
  • Exec Output – vision, budgets, staff, targets

The ideal candidate for a Product Management position is someone who has been in each of these roles:

  • They will have been in development or know enough to call BS. However, engineers who move into PM often find this hard as making a more “correct argument” doesn’t float.
  • “If you’ve never ridden in a car with someone who has a quota you don’t know sales”.
  • Executives care about keeping the company afloat.

Three different groups, with different skills and different languages. Hard to find this within one person, so you can try to build a team that does have those skills. Product Management is a hard job for anyone – “smart people go find something else to do eventually”.

Agile Planning Onion – Mike Cohn: Daily, Sprint, Release, Product, Portfolio, Strategy. Product Managers live in the middle – three to twelve month period – and bridge the strategy that Executives have laid down with the limited set of staff the organisation has.

Product Owner vs Product Manager

(Slide 5)

Does it depend on the company?

People from the Agile space – Product Owners – often don’t know how to sell and market products or how to get those products into the market successfully. Further, they often don’t know how to EOL a product or support the product when it is in production. They know how to build products.

Agile people often feel if you make it they will come, why won’t the world buy it. Emergent business model. We don’t know who we will sell this to, we’ll figure it out on the way.

The Product Manager is the wrapper, the overarching strategic folks that listen to customers/support engineers/sales people/developers/executives, and then set a direction, plan and price and market the product.

“Eric Ries brilliant” – taken direct marketing science and introduced to engineers as customer development. (as an aside we’ve got Eric Ries in conversation at Atlassian Summit 2012)

Product Owners Calendar

(Slide 8)

Lacking customer interaction. The Scrum definition of Product Owner doesn’t define anytime to sit with customers except for the time that customers join the demo and planning each sprint. Don’t confuse the customer showcase for the entire market.

If you are the PO that doesn’t get out of the building you failed. Yet Scrum training expects you to sit with the team and be able to answer all of their questions about the customer/problem.

“get out of the building” – Steve Blank

Agile will consume much more product management time – which is good. But if all you do is sit with your team – EOJ – End of Job.

A “small p product owner” lacks real input from execs, customers, etc and that  is a failed model.

Most Product Owner failure is due to not spending enough time observing customers, or they don’t know how sales and marketing work, or we promoted them from development and they are missing pricing, packaging, EOLing experience, competitive dynamics, and more.

Generally a promotion from engineering to PM  doesn’t have good connections to sales, marketing, support – all of which are a great source of input. Don’t just promote someone who is a good engineer to a PM – you lose a good engineer and don’t necessarily get a good PM.

Another challenge for the Product Owner is that they haven’t spent enough time with company strategy – optimise locally vs optimising a company wide strategy. Or you have a solo product manager who doesn’t prime the backlog – “build what I meant” – the PM who doesn’t know Agile.

So, really there should not be a split between the PM/PO roles. Fewer more experienced people works best.

Waterfall is conceptually easier as you believe in the fiction that the projections are correct, until 6 weeks before launch. A lot of companies run on Waterfall at the top and Agile at the bottom, and there is something bad that happens in between.

Technical Skillset

What are the weapons that a PM needs to have to work with engineering?

  • If you are not very technical don’t sign up for a technical product management job until you’ve built the technical foundation.
  • Engineers listen to you a whole lot more when you come from an Engineering background as you can call BS.
  • A technical team will write you off in a second in a highly regulated environment (finance/medical). Engineers will know if you are talking BS.
  • Consumer apps need a PM with a lot of taste, they need to know what the demographic cares about. Tech background is not as important.
  • Hire MBA’s in their second job out of college – so they no longer think they are the boss. Great hires if they have a technical background.
  • Helps to have a friend in the development team, even if not in the same company. You can ask the questions without showing too much weakness.
  • How can you gain technical skills? Start hacking. Build it now. Startup weekend.

How to transition from project management to product management? 

The job of a project manager is to get done the things we’ve promised to get done when we know we don’t have enough time or resources – how can we shave the edges to ship the thing we promised to ship? Can we shorten the QA cycle? Inward looking optimisation.

If I am on the product management side I ask what features to I drop to make the date? Outward looking optimisation.

Start spending more time with customers. Think about the pricing problem, competitors.

It is just as hard to go back the other way.

Better yet, build a team with complimentary skills. Have trust and happiness.

Resources:

Appreciate the notes? Please

In Events, Product Management ,
 permalink