Jan 14

Product Management 101

In early October, product manager Ellen Chisa visited HBS to give a talk on product management. Ellen brought years of experience in tech and product management to her discussion, having been a product manager at Kickstarter, a program manager at Microsoft, and an edtech startup founder. She’s also taught a course on Product Management at Franklin W. Olin College of Engineering, where she also earned a B.S. in Electrical & Computer Engineering. She’s currently the Director of Product at Lola.

Ellen also brought the uncommon perspective of someone who had spent a year at HBS and then taken time off. If you’d like to hear more of her perspective on any of these experiences, check out her blog at

Takeaways from the 80 minute session were focused from the perspective of the product manager practioner.

Here’s some of the key lessons interspersed with some examples from my personal experience working on digital product at Sears Holdings.

1) Product management is a set of skills to help get things done, not a defined role or function. Make sure you play to your strengths and work to improve your weaknesses

  • It’s about thinking at the intersection of the business needs, the design to meet those needs, and the technology to get things done.
  • A PM isn’t an expert in the how, but must be the chief advocate of the what. For example, PM’s answer the question, “What’s the right thing to build”. Engineers know “What’s the right way to build it”.
  • A PM’s authority is generally soft authority and must be earned. Creating a product roadmap requires convincing people who don’t report to you of your proposed plan.

Example: When I was at Sears, I led the Chicago-based strategy & operations team that collaborated with our Tel Aviv-based product and development team. Everyone had opinions on how our landing pages, profile pages, and product view pages should be designed. However, by centering all of us on a dashboard of analytics on customer activity, we were able to understand the business needs and create a roadmap to increase revenue and engagement.

2) User interviews are about the user expressing themselves and you synthesizing their responses

  • The questions should be scripted based on the areas you need to learn about
  • However, you should approach the conversation with an open mind and listen actively so that you can react and dig deeper as you go
  • Talk to several users from several segments. Don’t validate an idea without actually having heard it come from a broad survey of customers. Take care to not fall into the trap of listening for what
  • Synthesize and distill the result of interviews immediately. Try to summarize by saying “Our product is X to Y user group”

3) Building the right product requires you to understand client and stakeholder desires

  • Listening to the client is like listening to users. Listen to what they say and how they say it. What are they suggesting, what are they asking about, what are their priorities, and how do they react to your statements.

4) Writing specs has to start from a solid foundation

  • To do this properly, you have to a clear idea of where you are headed. A one-pager summarizing objective/vision, goals, key user scenarios and features, and success metrics helps serve as this guide. Later on, this document will help keep you focused as inevitably additional ideas come up.
  • From there, you can break specs down based on feature sets, user types, views/screens, etc.
  • Then create a full spec document, even if it’s just for you to keep it all together as project manager

Example: At Sears, my team launched a message based commerce service called Shopbolt. While we were envisioning the product, we wrote up single paged mock press releases to envision the features and impact of the service we wanted to build. This allowed us to focus on the key aspects of the customer experience.

5) Communication & Transparency are key, not the productivity tool that is used

  • Make sure you establish a team process that works with natural processes
  • Document what’s frustrating with the current solution used
  • Above all, adapt as is necessary
  • No tool is without fault, and no communication norm is without opportunity for improvement

Example: While at Sears, we went through fits and starts using Asana, Trello, Wanderlust. Eventually , we agreed on a daily standup document where a single priority for each team member was logged each day and overall goals were maintained in a backlog. In the end, it’s not the tool that matters, it’s whether the entire team is able to become part of a single tool that gets the job done for everyone

6) Manage Launch Process with Foresight – Create a Shipping Checklist

  • What test cases do you need to run?
  • For example: what browsers/devices does our service need to work on? Does it actually work on each of these cases? If yes, we can launch. If not, we better get on it.

Alex Mahylis is a first year fellow in the Boston chapter, and a MBA Candidate at Harvard Business School

Leave a reply

Your email address will not be published. Required fields are marked *