This is my second post in my product leadership series. Today I’m chatting with Ben Foster, VP product at Opower. For those who don’t know the company, Opower is a fast growing energy efficiency software company that helps utilitiesmotivate consumers to reduce energy usage. Ben is an excellent product leader with a wealth of experience in numerous environments. He has held product management and product leadership roles at Webvan , Ebay, and Adchemy before joining Opower. There are few product leaders with his depth of experience across both startups and large companies across consumer, ad tech, clean tech, and SaaS. He’s also a dear friend and was a collaborator in my early career. As I said in my previous post, the first step to great product leadership is a winning process. This interview focuses on the lessons learned from Ben’s various roles and how he is looking to create a winning product process at Opower. 

I’m not a journalist, but will keep this in a Q&A format.  It’s not verbatim, but the content was approved by Ben. 

RG: Tell me about the different product orgs you have been a part of and the strengths and weaknesses of each. 

BF: Webvan had a product team of about 6-8.  Each PM had ownership over a specific piece of the product, regardless of the scope or complexity of the product. Product management served the interests of the business units.  We focused on moving very specific metrics that was not determined by the product owners. The good thing in this model was that there was total role clarity.  The bad thing was that there was a very poor sense of product prioritization. It was primarily driven by gut feel and arguments. 

Ebay was a well oiled machine designed to push code live.  It was a very well structured waterfall process.  Ultimately, you got the results that the process managed towards: a huge number of features with the minimal level of quality required to meet the metrics.  And the metrics we focused on were things like lines of code in production, Product Requirement Documents delivered per quarter, number of bugs, etc.  There wasn’t a focus on elegantly designed solutions and a poor sense of what products would ultimately make an impact. Ultimately, I think Ebay’s product innovation struggled for a few reasons:

• Products were justified and measured based on an NPV analysis.  This works some of the time. But the importance of many products can’t be measured in this way.  Plus, we’d pad the numbers all the time to get products prioritized, so they ended up not really being that meaningful.  It contributed to the illusion that we could really quantify everything. 
• Occasionally unhealthy tension between the business team and the product team.  The units were separate and did not collaborate well and there was misalignment of goals.
• The fear of ruining Ebay’s “secret sauce”.  Products could be vetoed by the heads of various functional units if it threatened “the community”.  But no one really knew what made the business so successful, and so there was major resistance to non-organic change.  Our most vocal and successful community members were the very same people who benefited from the inefficiency of the Ebay platform.  So we had major disincentives to innovate. 
• Seller focus.  Sellers paid Ebay the money, so the company focused innovation on them.  We listened to sellers that said that they wanted feature X, Y, or Z.  But we missed what sellers really wanted.  What sellers really want is for buyers to think of Ebay FIRST when they want to buy something.  

Finally, Adchemy.  I joined Adchemy as their first full-time product person, and built the team to about a dozen folks before I left. There were two important learnings from Adchemy for me:

• First, I guided the shift in the product development process from waterfall to Agile. I actually hired someone to manage the process – sort of a technical project manager to really make sure that we were shifting to a consistent Agile process.  It was a very hands on role at first, but once the machine was going, that person transitioned to being a PM.  I would do this again if I ever had to make the transition.
• Second, I saw the challenges of being a product manager without taking full ownership of the product vision.  Because our founder and CEO was such a visionary himself and interfaced with customers all the time, I spent more time managing the team and focusing on the design of products.  I think this hurt me and hurt our team’s ability to collaborate on the vision of the products and prioritize the products and markets we would tackle.  

RG: So, this brings us to your current role at Opower.  Tell us about the organization you inherited and how you are organizing your team. 

BF: I came in as the only product leader in the company.  We had a team of a couple smart and capable PM’s, but who really had very little prior experience. So I could craft the entire process and take ownership of the product vision.

I’ve learned there are two ways to organize product teams.  

1. Organize around components (ie: product manager for transaction flow)

Pro’s: Clear ownership.  Long term continuity of knowledge base.  

Con’s: Work gets fragmented as each product gets looked at from a component lens.  You end up not focusing on the users’ real problem and your solutions are less creative and less comprehensive as a result.

2. Organize around initiatives

Pro’s: More focused on solving customer problems.  More flexibility and ability to pivot and experiment.

Con’s: Initiatives are transient.  Context ends up changing constantly, which hurts productivity.  Harder to continue to update existing products because there isn’t consistency of ownership. 

What I’ve decided to do at Opower is to create a hybrid structure. 

• 30% of a PM’s time is focused on component ownership. They lay out a roadmap and strategy to optimize their components or flows.
• 70% of a PM’s time is focused on delivering products that are end to end customer experiences.  
• Forces PM’s to develop products that overlap the domain of others, thus forcing collaboration. 
• Any PM can work on any initiative, and engineering team is organized by initiatives, not components

RG: What process do you put in place to understand customer needs?

BF: Customers tend to be good at describing their pain points, but are rarely good at solving them. We try to talk to our customers frequently and really dig into why they want what they think they want.  It’s probably the skill that most distinguishes a good product manager from a mediocre one. A couple tactics that I find useful:

• Have some methodology for root cause analysis.  It can be as simple as the 5 why’s. 
• Find different ways to get users to better articulate their problem.  One that I find interesting is “Product Box”, which is a game where you get users to design a product box they would buy and present it to you infomercial style. It helps articulate why the customer believes the solution will solve their problems.
• Create a market and advisory panel.  This is a reliable system to get the right types of people in front of your product and engineering teams on a regular basis. Figure out the personas of end users you are targeting, and then recruit the right mix of these folks to give you feedback on an ongoing basis.  We are building this now at Opower and had this at Ebay through their Voices program. 

RG: How do you manage and prioritize the product roadmap?

BF: 

• When you can truly quantify the benefits of products, do it.  Just know when you are kidding yourself.
• Identify dependencies in the business and the critical path items that are slowing things down.  Focus products on those.  It seems obvious at first, but gets complicated as a company scales.
• Do what I said above in terms of organizing the product team and training them to understand the root issues of users.  It’s vital for making wise decisions when making judgment calls on prioritizing products with subjective value vs. easily quantifiable impact.
• Maintain a very close relationship with sales (primarily important in enterprise software). I spend a lot of time with our head of sales and give him a “budget” of man-hours for new deployments.  It forces him to prioritize the items that are important in closing a sale and helps me understand customer requirements better. 
• Create a roadmap with the right level of granularity and measure actual products delivered against it.  At Opower, we have a 12-18 month detailed roadmap.  We measure the % of features that we actually end up building.  The number should be between 60-75%.  If it’s too high, it probably means that we aren’t working hard enough to collaborate with customers and pivot as their needs evolve.  If it’s too low, it means that our product vision stinks and we don’t really understand the root causes of the problems our customers face. 

RG: Finally, want to add any points on actual product execution?

BF: I’m a pretty strong believer in Agile, and there are plenty of good books out there that I think can describe good processes better than me.  It’s kind of a commodity.  What I do is add a little more documentation vs. what’s typically suggested in Agile.  The concept of “the product is its own documentation” doesn’t work as well in highly algorithmic products or ones with a lot of configurability. It’s also difficult when you are scaling a company quickly, because it’s hard to onramp new recruits.  And we’ve been growing at more than 200% per year over the last few years, so that’s actually pretty important to us.

RG: Thanks Ben. Congrats on the success of the company – you guys have an inspiring mission and we’ll all be better off the more you are successful.