Monthly Archives: March 2014

On my radar – week of 3/24/14

Product Camp Silicon Valley – Product Management in a Lean Startup World

The second session that I attended at Product Camp Silicon Valley was titled Product Management in a Lean Startup World, led by Dan Stiefel (@DanStiefel). I’ve met Dan at a couple of San Francisco based Product Management events.

He is very active in the Lean Startup community in the Bay Area and is one of the people behind Lean Startup Circle. There were some good takeaways for me in this session. It reinforced the basic ideas of Lean and there was some spirited discussion about the Lean hype cycle and how many of the Lean Best Practices are things that successful entrepreneurs have been doing before Lean became a buzz word.

Here are my notes from the session…

Dan ran this session using the classic unconference format. No prepared slides and he made it clear from the beginning that we were all going to participate. This is the format that I prefer, so the session was off to a good start.

To make sure everybody in the room was on the same page, Dan asked attendees to provide definitions of some of the Lean terms and then offered some of his insights.

Basic premise of Lean
Test a hypothesis, validate it in your market

Minimum Viable Product aka MVP

  • Helps you to avoid spending 18 months building something that nobody wants
  • You know that it’s missing things but you want to put it out there
  • Your MVP should be tied to a question / hypothesis

Product / Market Fit

  • It really solves something
  • It doesn’t just fit for one or two customers
  • You’re looking for market fit
  • Compare your product to the next best thing that is available. What is your competitive advantage?

It’s important to hold yourself or someone in your organization accountable for the outcome of the testing of your MVP. It’s really easy to make excuses about why the test failed – e.g. you don’t know what a 2% conversion means, so you dismiss it and continue moving forward with your product. Before you validate your hypothesis, it’s important to understand how you define success and what your most important metrics really mean.

Equally imortant is having a plan for what you’re going to do next after you see the results of the test, even if it’s not the result that you were hoping for. The key thing is that you learn something and adjust the course of your product based on what you’ve learned.

Challenges along the way…

Sometimes the peson who is holding the purse strings already has in mind what they want the product to be and they want to use the Lean process as “proof” that this is the right decision. This is a tough environment because you should be prepared to go in a different direction and not be overly attached to the original idea.

Someone made the point that they were practicing Lean long before any of this Lean terminology came along and that most of what was being dicsussed is nothing new – i.e. all of these Lean buzz words is just repackaging of things we’ve been doing along. I thought Dan did a good job of acknowledging this point and reinforcing that one of the goals of this session is getting past the buzz words and talking about what it really takes to do the hard work that is needed to successfully practice Lean.

Some advice when you are talking to customers or potential customers…

Ask about their pain points and what problems they are trying to solve without pitching your product. You’ll be much happier with the results because they’re going to be more open about their problem space and they won’t narrow it based on what they think your product is supposed to do.

Someone in the room said that the most successful startups in Silicon Valley acted as if you had already solved the problem before they had a complete solution. Someone else made the point that passion and belief in your product is important but you can’t allow the passion to make you overly attached to your original idea.

Another problem that people in the room faced is working with a really smart set of engineers who have built something really cool but have no idea if someone will pay for the product. This type of organization can really benefit from Lean.

Need passion without the attachment.

Pivot vs Persevere
Pivoting means that you change direction based on something you’ve learned. You’re still using something that you’ve already built, so you aren’t starting over from scratch.
If you’re staying the course based on some confidence that you’ve achieved or are close to achieving product / market fit, the you are persevering.

A question came up asking how Lean fits in with Agile. Lean is more about what to build. Agile gives you a way to build it faster. When you’re using Agile to build something the question to ask yourself is: are you building the right thing? Lean can help you with this.

There was also a question about the name of this session “Product Management in a Lean Startup World.” Is Lean only for startups or can it also be applied to Enterprise? Dan made it very clear that Lean is not specific to startups and definitely has a place in Enterprise.

Continuing the conversation

The hour flew by and we didn’t get very far into topics such as where exactly does the Product Manager role fit into Lean and what are the differences between practicing Lean in a small startip versus a large enterprise. Dan proposed that we use the hashtag #LeanStartupProdMgmt for continued conversation about this.

Product Camp Silicon Valley – Has Agile Broken Product Management?

Yesterday I attended Product Camp Silicon Valley at the PayPal campus in San Jose. It was my second time attending this in the past 4 years. If you haven’t been to a Product Camp before, I highly recommend it if you’re a Product Manager who wants to stay on top of the latest trends in Product Management.

The first session that I attended was “Has Agile broken Product Marketing?”, led by Steve Johnson (@sjohnson717) from Under 10 Consulting. The basic idea of this session was that we as Product Managers need to keep in mind that the Agile process was conceived as a development methodology and it’s really just one part of a Product Manager’s job. It doesn’t guarantee that you’re building the right thing and it has little to do with domain or market expertise that you need to be a well rounded Product Manager. Overall it was an excellent session with many good takeaways. Here are my notes from the session. You can download the slides from Steve’s site.


Steve started out by saying that this talk is not about beating up on Agile. There are wonderful aspects of Agile.

Make sure that your user stories are not just descriptions of tasks. What problems are you solving?

Some people in the organization miss the old Waterfall approach. Sales people and execs pine for Waterfall but they tend to forget that the roadmap was fiction. Nothing was ever delivered on time.

Steve gave an example of Agile using his recent kitchen remodel as an example. They worked with their contractor to design a very cool pull-out shelf for a KitchenAid blender. But after it was installed, they realized that there was no outlet in reach to plug it in. No problem – the contractor adjusted quickly to this and installed the outlet and they move forward. They used Agile. If this was Waterfall, this would be more of a big deal becasue the outlet wasn’t in the original requirements. There would be a new quote for the additional work and it would be a much more difficult process.

Steve recommends having just enough process to get the work done. Keep the number of artifacts to a minimum and also try to have a minimal number of products.

The Product Manager role used to be a business role but over the years it has become more technical. You shouldn’t lose sight of the business drivers that are driving your backlog. He gave an example of a guy that he saw at the airport who was flipping through index cards. When Steve asked what he was doing, he said that he was grooming his backlog. He asked him how he knew what the ranks should be. The guy replied that he decided for himself which user stories were the most important. Don’t fall into this trap. When you’re grooming your backlog, you should always be working with your customers and stakeholders to inform your decisions related to ranking of user stories.

Other tips…

Another thing to avoid is building a cool feature that is targeted to a personna that is not one of your target personnas.

Remember that the Sales group is going to need to sell your product and also keep in mind the operational impact.

Steve mentioned a phrase that a fellow product manager named Saeed Kahn likes to say: “Nail it before you scale it.”

For example, you can show a new product release to two sales people before you show it to anyone else from Sales. Make sure that they understand the value proposition and know how to sell it. Once you’ve nailed it with the two sales people, then you can roll out to the rest of the Sales organization.

Extend your view beyond just the “nerdy” parts of the product.

Remember – one sentence from an exec (“I want this feature”) can be months of work for the Product team. To avoid a lot of wasted work, every week you should validate what you are building with that exec to make sure you’re still on course. You want to avoid getting to the end and them saying “That isn’t at all what I wanted.”

Some of the developers that Steve has worked with came up with a term called “Requirements aging”. When you get a feature request from someone, put in on the shelf for a while. Give it some time and the requirement will surely change.

What is the difference between the Product Owner role in Agile and the Product Manager’s role?Product owners are inside the building and represent the Inbound product management functions. Product Managers should be “outside the building” and represent the Outbound role too.

There are different types of product managers…

– Tech
– Biz
– Market

How many PM’s should you have in your department?
How many departments are hiding head count in Product Management?

You can keep the PM team smaller if departments aren’t pulling PM’s in too much for functions such as Sales demo’s.

Don’t be the product managers who hates customers.


Four areas of expertise for a product manager:
– Business
– Market
– Domain
– Technology

Most product managers don’t have all of these skills. Two out of four is more common.
Many technology companies think they can find people with all four but this is very rare.
Best thing is to have a mix of people in your PM group representing these different Skills areas.

Wrapping up…
We’ve focused so much in product because that’s where all the noise is, but remember to work on your skills in the other areas to be a well rounded Product Manager.

There was a problem connecting to Twitter.