Anyone Can Be A Product Manager, But What Makes A Great One?


I am a self-taught product manager. I made the transition from a software developer more than a decade ago.

In the past 3-4 months, I’ve been recruiting for a product manager to join my team. A question I often ask is “What makes a great product manager?”  As Chef Gusteau exclaimed that “Any Can Cook” in Ratatouille, almost anyone can become a PM, but not everyone could be a great one.

Undoubtedly, product management is one of the most undefined roles in an organization. Unlike software engineers, product managers don’t have to code. Unlike data scientists, they don’t need to know statistics or machine learning techniques. But great product managers have many intangible qualities that make them exceptional.

  • A great PM studies and understands market dynamics. For example, someone working in the gig economy should follow the Uber China-Didi merger and understand how that might be bad news for Lyft.
  • A great PM is intellectually curious. He or she tries new products, formulates opinions, and evangelizes great products to others. Ask to see what apps they have installed on their smartphones.
  • A great PM has hobbies and talents outside of work. Some of the great PMs I know love photography, painting, gardening, cooking and building robots. They apply the same passion and discipline to their extracurricular activities.
  • A great PM inspires. Whether one is in a product or engineering-focused organization, a PM can always inspires others through narratives.

Keep my fingers crossed. I hope I will find that elusive one soon!


How To Influence Others


I attended our company’s 3-day offsite where product, design and ops gathered.

On day 2,  our group did a “trust-fall” like game.  The goal was to communicate verbally, while blindfolded, to get the 15 people holding one rope to form a perfect square.  Our team had many strong voices in the beginning, but we finally followed one person and ended up with a rectangle, not quite a square but at least with 4 corners.

The takeaway was quite insightful.  There are many tactics to influence others.  The ability to persuade others is a key trait of a great product managers.  Here are some levers one can adopt.

  • Legitimizing – leverage an authority figure or validate with credible sources, e.g. the CEO asked for this feature. Personally, I avoid this approach as much as possible.  However, some may readily respond to this approach.
  • Appeal to friendship – building a strong network means that you can find someone who knows someone to get a problem resolved or a question answered.  This helps you win others over to your idea.
  • Logical persuasion – use data to prove your case.  While this is my go-to tactic, this is not necessarily effective for everyone.
  • Socializing – get your idea across the organization by meeting with others one and one.
  • Consulting – ask others for feedback.  Often this is a great way to start a dialogue about an idea you want to get across.
  • Stating – articulate and reinforce your ideas and rationales.
  • Appealing to values – persuade others by appealing to a shared value, e.g. one common goal to get the product launched on time.
  • Modeling – demonstrate to others how the idea or approach can work.
  • Exchanging – quid pro quo.  If you do this for me, I’ll return the favor..
  • Alliance building – if you take on a really challenging task with many naysayers, build up allies first before facing strong objections.

Not all methods are equally effective.  The key for a PM is to broaden tools in his or her toolkit and try a few until you can win others to your ideas!

The Intangible Qualities in a Product Manager

One of the most challenging tasks in my job is recruiting and building out a team. Whenever I am asked to draft a job description, I ask myself these questions:

  • Does someone need to have 3 or 5 years of experience?  Does the sheer number of years really tell me how good they are coming into my team?
  • Does this person really need a Computer Science or Engineering undergrad, or someone who can earn respect from engineering to establish a great rapport?
  • Does this person even need to have domain knowledge for what I am looking for?

There are many things I don’t include in a job description that I look for in a product manager.

Are they naturally curious?  Do they try out new products & services? Are they early adopters or laggards in new technologies?

Do they have an opinion about good and bad design in products?

Do they demonstrate good judgement in past product decisions?  Are they able to defend their positions?

I don’t typically add these as job requirements or even “bonus” qualities.  They surface from a good conversation during interviews.  These are what I call “The Intangibles”.  When you find someone who meet these 3 criterias, consider hiring them.  Ultimately, it really doesn’t matter whether they meet any of the “official” qualifications.

Big Data Is De Rigueur In Product Innovation



I recently attended a Kellogg alumni workshop on “Big Data Doesn’t Make Decisions, Leaders Do”.  Coincidentally I also came across this WSJ article on b-schools re-vamping curriculums to include data analytics.

My takeaways:

  • Business leaders need a working knowledge of data science to be effective in leading with analytics.  In other words, they must be able to nterpret analytics to inform their decision making.
  • You can outsource the infrastructure of big data and data analytics; you cannot outsource product management.  A good product manager is essential to connect business problems with data science findings.

Data science is about discovery – learning about what’s going on in your business.  Product management is about innovation – taking the business to the next step and use data to experiment along the way.

I came across a number of online courses to learn more about data science.  Here’s a link to Cousera’s data science specialization.  I welcome your input and comments are to what courses you’ve taken and found valuable.

Blending Art And Technology


sketchesOver the weekend, my family visited Exploratorium at its new location at Pier 15 in San Francisco. I was especially drawn to one exhibit and its blend of art and technology. It was a contraption that created a pencil sketch drawing of a video footage of me in real time.

The concept is so simple, yet elegantly executed.  That’s what products should be – hide all the complexities from users, show a simple user interface and output something that is beautiful and delightful at once.

Three Legged Stool

To create a successful product, three functions must come together: engineering, design and product, much like a three-legged stool.  If one function is broken, you are unlikely to have a great product.


For this partnership to work, each function has its role.  It’s the Product person’s job to articulate the “why”, and Design and Engineering to figure out the “what” and “how”, respectively.  Some tension is natural.  My philosophy is that some heated debate is healthy.  No one should take things personally, since debates push more clear thinking and help flesh ideas out.

In terms of Product’s “why’s”, it’s the Product person’s job to answer a few questions:

  • Why are we building this product?
  • Who are we targeting?
  • What is the market landscape?  Who are the players in this space?

It’s Design’s role to articulate the “what”.

  • What’s the overall user experience? In the case of a mobile app, this ranges from the onboarding experience to navigation to rewards to sharing with others.
  • Visual design – from color palette, font selections, etc.

It’s Engineering’s role on “how” is to determine the technology stack that can accomplish said product.  Engineering should be primarily concerned with performance, scalability, and flexibility (tweaking features as a product finds product-market fit).

I mentioned three functions above, not three people.  In some cases, it’s necessary for someone to take on multiple roles.  This is often the case for new products, when someone has a new idea and wants to prototype a product, or even launch an MVP.

I’ve worked in a number of startups and bigger corporations that don’t have a designer on staff. I take on the role of an interaction designer and then seek out the support of a visual designer.  That’s never ideal but is necessary to move projects forward.

While I did not explicitly include a QA lead in the paradigm, this role is often combined with engineering.  Bringing a QA lead into the discussion early is always helpful as he or she often helps identify failure use cases based on experience with other products.

Regardless of how many people you have to get started on a project, having a strong Product person who can articulate a clear vision on “why” we are building this product is crucial.  Without one or someone to take on that role, you may not be building the right product to begin with.


Saying No Is Hard But Necessary

People want to be liked.  So naturally you want to say “yes” to people who asked.

As a product manager, having the confidence to say no to a feature is a necessity. Building a product is all about focus.  Focus on your target audience and strive for simplicity.

Kevin Systrom, founder of Instagram, began with a complicated location-based iPhone app, named Burbn, that let users checkin and post pictures of meet-ups with friends. Kevin and his colleague Mike Krieger used analytics to determine how their customers were using Burbn and learned that people were using the photo-sharing, not the main check-in, features.  They decided to focus on their photo-sharing infrastructure and eliminated almost everything else.

This is a case of saying “no” after a product has been built.   Emotionally, it’s really hard to kill features.  But you have to consider all your investment as “sunk cost” once you learn that something is not working.


Books About Silicon Valley Founders

I love listening to audiobooks on my daily commute.  It’s challenging to find free blocks of time to enjoy books on weeknights and weekends, which made my 40-minute commute each way a blessing in disguise.

I love “reading” about biographies or memories of Silicon Vally startup founders.  Here are my favorite ones:

51S2iJN3DYL._SL80_51j1P236E3L._SL80_  61zCMnP6nZL._SL80_51ysl-BDgGL._SL80_  51ULBoVSTcL._SL80_

  • Steve Jobsby Walter Issacson
  • The Hard Thing About Hard Things: Building a Business When There Are No Easy Answersby Ben Horowitz
  • Hatching Twitter: A True Story of Money, Power, Friendship, and Betrayal by Nick Bilton
  • Delivering Happiness by Tony Hsieh
  • Rework by Jason Fried, David Heinemeier Hansson
  • The Everything Store: Jeff Bezos and the Age of Amazon by Brad Stone
  • Creativity, Inc: Overcoming the Unseen Forces That Stand in the Way of True Inspiration by Ed Catmull and Amy Wallace

Other books I am reading or in my Audible library are:

  • The Innovators: How a Group of Hackers, Geniuses, and Geeks Created the Digital Revolution by Walter Isaacson
  • Zero to One by Peter Thiel, Blake Masters
  • The Launch Pad by Randall Stross

I am always looking for book recommendations….Please share yours.


Three Levers In Product Development

As a product manager at startups, I am often put in charge of overseeing engineering and delivery schedules.  Along with the number of hats I wear, I am fortunately afforded more levers that PMs typically don’t have.

Over the years, I’ve come to realize that there are 3 main levers in building and launching products.


  • For a new product, decide what is the minimum set of features to include to determine there is a product-market fit.
  • For an existing product, assess the incremental set of features to meet immediate customer needs and differentiate from competition.

In both cases, it’s important to be “ruthless” in cutting out features that are not crucial.  In my last job at Reverb, I was tasked to launch the iPhone app as a follow-on release to the iPad version already in the market.  It’s both a new product (in terms of device/form factor) and an existing product (server-side functionality remained mostly the same).  After considering iPhone usage patterns, I decided to cut out an edit-heavy feature (creating and editing a collection of articles).  That significantly reduced the project scope and simplified the user experience.


At launch, I always make sure that there are no showstoppers/crashes (P1) and critical bugs (P2), those include illogical user flow, typos, functionality not working as described).  Assessing the criticality of each bug is mainly the role of a product owner (using Scrum speak), supported by a QA colleague.


Most Internet software companies are adopting Agile.  At end of each sprint, there should be a releasable candidate (theoretically), but it’s not always the case.  While I respect the philosophy behind Agile, you really need to build in time for integration testing and device compatibility testing, particularly for mobile apps and responsive websites.

With all that said, holding quality constant, you are really down to two levers – features and schedule.

  • Schedule – it’s not in the spirit of Agile/Scrum to set a release date in advance, but it’s often necessitates by market timing (e.g. consumer electronics targeting Q4 in retail channel, promotion in time for Dads & Grads in June, etc).  In the case when a schedule is inflexible, push back on new feature requests and actively work to manage the scope of committed features.
  • Features – when a feature is crucial and must be included in the next release, the schedule becomes a secondary consideration.  When iOS 8/iPhone 6 were released, we ran into issues with an early release of Xcode 6 in terms of auto layout.  It then took several days before we resolved the auto layout issues to support both iOS 7 and 8 devices.  I held up the release and “ignored” our original launch schedule.

In summary, you have 3 levers, but cannot be prescriptive about all 3 at once.

I would love to hear what other considerations or levers you see in terms of building and shipping products.

Intuition Vs. Data-Driven



Much like the decade-long debate on nature vs. nurture, there has been much discussion on whether product management should be intuition vs. data-driven.  I’ve often been asked what type of product manager I am – the intuitive (aka. fly by the seat of my pants) or data driven (aka. don’t do anything unless the data justifies it) type.

Product management requires a healthy mix of product intuition and data-driven decision making.  You have to find a balance.  Product intuition about what to build, whether you have product-market fit, whether this feature is part of MVP is all forward-looking.  Where as data-driven decision making, e.g. whether to deprecate a feature because of its low usage or does the A/B test result show a statistical significant improvement, is backward-looking.

Ingenuity and intuition are necessary to come up with differentiating features that make your product stand out in the marketplace.  Looking at data closely helps you make informed decisions about an existing product.

My first job out of Kellogg’s MBA program was a product role in the Marketing group at Netflix.  My job involved running pricing tests, redesigning the free trial funnel, and shepherding a number of non-member site changes.  I ran dozens of A/B tests and analyzed results before making a site change recommendation.  In that role, I made decisions primarily based on data.  Because pricing and user acquisition were so closely tied to revenues, my job involved a lot more data analysis rather than defining new features.

Fast-forwarding nearly a decade, I was in charge of redesigning the TechCrunch redesign in 2012.  To begin, I re-imagined how the tech blog could be organized, how I could bring videos much closer to the rest of the site, and how the river (of stories) could be less monotonous, and so on.  I had the charter to keep the engagement up (retain or increase all page views), as well as bringing a modern feel to the site (making it both responsive and highly performant).  The major redesign project requires a lot of thinking about how to do things differently, improving reader experience and writer productivity at the same time.  Once I pulled the data on engagement and traffic numbers, the rest was making product calls every step of the way.

As for me, I adopt a blended approach, slightly tilting toward the intuition side.  I don’t believe in purely making calls intuitively.  Even my personal hero Steve Jobs made mistakes with Lisa and NeXT, lacking product-market fit.  However, purely basing everything on data means that you are hampered from experimenting.  This is particularly crucial when you are entering a new market or defining a new feature.

Apple and other like-minded companies use an intuitive approach to create products.  Consumers don’t know what they want.  Henry Ford, on innovation, said, that “If I had asked people what they wanted, they would have said faster horses.” Other successful tech companies, including Amazon and Netflix, fervently adopt a data-drive decision making approach.  Both can be successful.  Having worked at a number of tech companies, I’d like to share scenarios in which one approach is more applicable than the other.


  • You are developing an MVP (minimum viable product).  Make the hard call on what is necessary in your first version.
  • Usability – you should use beta users or existing customers for feedback on products once the project reaches the “feature complete” milestone.  However, if your gut always tells you that this doesn’t work, trust your instinct.  You won’t find a good test result from a feature you yourself don’t believe in.

Data Driven

  • You just launched a new feature.  Track its engagement for a week, a month, 3 months.  Don’t over-react when a feature is not doing well initially.  After a one month for most consumer products, you’ll see a steady pattern.
  • Pricing changes – any revenue-impacting changes should be tested via A/B tests.
  • Product design – I am not talking about visual design.  You can show mocks to friends, coworkers and family to get some feedback.  It’s easier to get and swallow harsh feedback before you invest time in coding an iOS app.  Much easier to get the feedback when it’s in the “mockup” stage.

I would love to hear from fellow product folks about when you should trust your instinct and when you should examine data thoroughly before making a product call.