Tag Archives: product management

What makes a great product manager?

Posted on by

This week I had the good fortune of attending a fantastic mentorship event for product managers organized by Josh Elman and Mina Radhakrishnan. In small groups, newer PMs had the opportunity to ask more experienced PMs questions about any topic related to product management or being a PM. One of questions in my group was, “What makes a great product manager?” I answered the question (hopefully helpfully!) by sharing what I look for when hiring a PM.

It begins with my firm belief that you need to hire PMs for attitude over aptitude. Product management done the right way is an unglamorous job executed with no formal authority. It requires PMs to accept that they need to be shit umbrellas and credit funnels. The job cannot be done without having as much EQ as IQ. And while many product management skills can be learned, I’ve found that attitude is something that can’t be taught. So hiring great PMs starts with attitude. But there are also four categories of skills that I believe are important for PMs to have in order for them to be great.

Product insight. Insight begins with empathy with the user. The best product managers are able to imagine themselves in the user’s situation and develop products that address the needs identified in those situations as simply and powerfully as possible. At the same time, they’re able to use data, ideas and feedback from many sources to inform and support the product decisions made in response to those needs.

Product execution. Potentially nothing is more important for PMs than the ability to just get shit done. No amount of insight compensates for an inability to help teams ship products. And that requires a relentless focus on doing whatever is necessary; to be the person who fills all the gaps and helps others to be successful. Great PMs are able to prioritize and do a small number of the right things incredibly well.

Over-communication. The best PMs establish trust with those around them, making themselves and their teams more effective as a result. I’ve found that the best of way of developing trust is not just by communicating, but by erring on the side of over-communicating. Great PMs need to be both willing and able to communicate clearly, concisely and often to make sure their teams have shared goals and that everyone impacted by product decisions has a shared understanding of why those decisions are being made.

Leadership. PMs need to lead without any formal authority. They inspire and motivate by articulating a compelling product vision and strategy. They establish credibility by setting clear objectives and roadmaps in partnership with their teams. And they earn trust by being honest and accountable. No PM accomplishes anything without a team that is willing to be led by him or her.

Because I believe that these “soft” skills matter much more than “hard” skills, I’ve sought out and been able to hire great PMs who come from all sorts of backgrounds. If you’re fortunate enough to come across the rare PM that has both the right attitude and demonstrated aptitude, definitely hire him or her. But if you meet a PM candidate with a stellar attitude yet only high potential aptitude, I’d encourage you to bet on that person. That bet will pay off in spades for both of you.

Know what you’ve learned, not what you’ve done

Posted on by

At Homebrew, Hunter and I are very focused on “Why” a founder has chosen to start a company and what motivates him or her to attack the specific problem or opportunity he or she sees.  But also important is the “how”, the approach the entrepreneur has taken to address the opportunity.  Often, when we starting talking about the “how”, we hear about a lot of different ideas being considered and experiments being run in an effort to find product/market fit.  But at the seed stage, entrepreneurs often focus only on what they’re doing without being equally attentive to what they’re learning.  “Being busy” by itself does not equate to building a company. You should be learning with every step so that you can find a scalable model of success.

Focusing on the key questions and how best to answer them

To create an organization that learns and doesn’t just do, I’m a big advocate of the scientific method approach to building product (and companies more generally).  The scientific method is a simple framework that can help startups focus, experiment, learn and iterate quickly and effectively. Below is a description of that method along with a simplified example of an experiment we ran at Twitter (not the actual data).

Purpose/Question – As obvious as it sounds, you need to start with the question you want to answer.  Surprisingly, lots of startups take the “see if the spaghetti sticks” approach, just putting something out in the world and then somehow gauging the response.  Without clarity around what question you want answered, it’s difficult to design the right experiment and to draw the right conclusions from the data you collect.  In particular, it’s critical to know what metrics are relevant to the question you’re trying to answer.

Example: How can we increase the sign up rate of users visiting the Twitter homepage?

Twitter homepage in April 2011:

Research – If you have a question, it makes sense to consider all of the potential answers, even if many of them are dismissed quickly.  Research, whether that’s talking to potential users, evaluating similar products, conducting simple surveys or brainstorming as a team, does a few things.  Research helps uncover unspoken assumptions about the answer, identify unexpected potential answers and inform the design of the right experiment.

Example: Ideas that emerged from user research, looking at site analytics and from team ideation included better descriptions of what Twitter is, a video that explains how to use Twitter, showing popular tweets, simplifying the homepage by removing trending topics, simplifying the homepage by removing the search box, etc.

Hypothesis – What do you believe to be true?  That is the essence of your hypothesis.  And proving or disproving that statement is the goal around which your experiment should be designed.  Any test run without a hypothesis is unlikely to lead to learnings that impact product direction in the correct way because the experiment likely doesn’t have a control for what you believe to be true.

Example: Simplifying the homepage to focus on sign up by removing the search box will increase the sign up rate.

Experiment – This is what most startups focus on but only in the sense that experimentation means putting something out in the world.  More important than the idea of experimenting is the design of the experiment.  Simply put, you need to know what question you’re trying to answer, which answer you believe to be correct and which variables you believe impact that answer.

Example: Show the homepage without the search box to a randomly selected, statistically significant sample of users and compare the sign up rate to users that see the existing homepage during the same period of time.

Analysis – The reality in most product experiments is that you can’t isolate or control all of the variables, so it’s important to not be a slave to the data.  Data from the experiment usually needs to be considered one input into product thinking and not the answer in and of itself.  Accordingly, it’s critical to be honest about what the data does and does not say in relation to the hypothesis and question at hand.

Example: The sign up rate increased by 12% without the search box. But by removing the search box did we lose sign ups from people who searched and then signed up from the search results page?

Conclusion – In organizations both small and large, nothing is more important than providing the proper context for product decisions.  So when you arrive at conclusions from your experiment, be sure to share them quickly, clearly and repeatedly.  Was the hypothesis proven or disproven?  Did the outcome result in more questions and experiments or answers that you feel comfortable moving forward with? Communicate what you intend to do in reaction to the conclusions and start the scientific method process all over again.

Example: At Twitter, results from experiments and planned next steps were summarized and emailed to an internal mailing list for anyone in the company to review.  When changes went into production, another email was sent outlining the changes.  

The homepage that resulted from this experiment and several others was launched in December 2011.

Here is the current homepage:

Next time you’re working on experimenting and iterating to get to product market fit, remember the scientific method.  If you remember to have a hypothesis and to design an experiment that tests that hypothesis cleanly, you’ll be learning and not just experimenting.

Better isn’t good enough

Posted on by

I previously wrote about what I think is required for a successful mobile product.  With all of the activity in the social messaging/communications/networking category (Whisper, Confide, Secret and Wut being the latest buzzed about apps), I thought I’d dig into one of the key points I made, which I believe is even more true in this category.  It’s not good enough to be better, you have to be different ─ in a way that helps address an entirely different use or possibly a similar use case dramatically differently.

In the case of messaging, it’s not enough to innovate along an existing dimension.  You need to create an entirely new product dimension.  It’s clear when you look at the breakout messaging apps that they clearly did something different relative to the apps that came before them, and in most cases that helped those apps address different user needs.  Facebook popularized status updates within a private network.  Twitter made status updates public (changing who sees the update).  Instagram made status updates visual (changing the format of the update).  WhatsApp made status updates (via SMS) free.  Snapchat made status updates ephemeral (changing the permanence of updates).  And what of the apps that were hyped and have seemingly gone away?  What new dimensions did Path, Frontback and MessageMe introduce?

Of the “hot” new apps, it remains to be seen which will pass the test of time.  Whisper makes public status updates anonymous (changing who sent the update).  Confide has made text status updates private and ephemeral.  Secret has made the anonymous status update visible only to a semi-private group.  Wut has anonymous, private and ephemeral status updates(?).  Are any of these apps introducing new dimensions that address different use cases or needs?  Fortunately, or possibly unfortunately, social messaging companies doesn’t typically fit our Bottom Up Economy thesis.  So we don’t have to bet which of these products will become the next Facebook, Twitter or Instagram.  But if I had to bet, I’d pick the one that does the most different thing best.  Because better just isn’t good enough when launching a product.

Four truths about mobile products, user mindset and achieving scale

Posted on by

Like many others, I’m spending more and more time on my phone, and I’m not making more calls.  I’m getting information, buying stuff, collaborating with others and much more.  There are a handful of mobile apps that I use religiously to do these things.  Why do I use these specific apps as regularly as I do?  I suspect that the answer for me and for many others who have the same behavior (a few select apps used frequently) boils down to a few simple things.

Scale is the outgrowth of doing just one thing really well.  WhatsApp, Instagram and Shazam are great examples of products and companies that expertly address a single, well-defined need in a simple way that satisfies a large number of people.  They haven’t added tons of new features to address additional use cases or at least they didn’t begin to do that until they had already significant user scale.  A single-purpose app makes it easier for a user to remember why she should use that app at the moment that she has a specific need.

Users inherently have a tendency towards mental inertia.  Once a user begins thinking of an app as addressing a particular need, it’s really hard to get him to think about it or use it differently.  An app developer who adds lots of features to an app risks confusing users and detracting from the core use case that the app is meant to address.  Unlike the desktop web, where tabs, menus, filters, etc. can be used to add features, it’s likely that in the mobile world the only successful way to add features will be to build entirely separate apps (see Twitter’s Vine and Facebook’s Messenger), often under separate brands.  Can you think of a single app that you use that does many different things well?

Better isn’t good enough.  Once a user begins to think of an app as addressing a need well, it’s really hard to get him to switch to another app to address the same need, even if it does it “better” (see Facebook’s Poke vs. SnapChat).  It’s not enough to be better in mobile, you need to be first to get to scale or you need to be different to fight inertia (not to mention switching costs, network effects, etc.).  WhatsApp continues to thrive in the face of increasing competition because it was first to address a specific need well.  SnapChat and Instagram succeeded not only because they did only one thing extremely well, but also because they did something different from Facebook and Twitter.  They addressed entirely new use cases and didn’t settle for competing via marginal feature innovation (which seems often to be the case in the messaging category, as one example).

Great products unlock user acquisition.  How did Uber grow virally?  The challenges of mobile app discovery and distribution have been well documented. App store distribution, pay-per-install ads, incentivized referral programs, etc. all face obstacles in mobile.  If you don’t have a product that requires users to invite others to benefit from the app (i.e., Facebook), there is only one true answer to the distribution problem.  The best distribution strategy is to build a killer product that generates tremendous word-of-mouth.  Uber, HotelTonight and Mailbox are examples of mobile apps that delivered amazing user experiences that in turn led to viral growth via word-of-mouth.  More than ever before, being the first to deliver an elegant solution to a user problem can be the key to dominating distribution and hence an entire market.

Surprisingly, when I thought about the points above, it seemed that what is true in mobile has largely been true on the web as well.  While technology changes, human behavior is pretty ingrained.  The mind craves simplicity and consistency and resists complexity and change.  Mobile app developers who want to achieve scale will be well served by satisfying the mind.

Shared Context in Product Development and the How of “Why”

Posted on by

Product development doesn’t come without its fair share of strong points of view, impassioned debates and occasional yelling.  These disagreements don’t result from team members wanting to do the wrong thing.  Instead, arguments about priorities, features and timeframes are typically caused by the lack of shared context about “why”.  Whether you’re a product manager, engineer or designer, if you’re the “decider”, your job is to make sure that everyone on the team has a clear understanding about why the goals, priorities and decisions are what they are from the very beginning of your work together.  Without shared context there can’t be shared purpose, shared risk or shared outcomes.  Here are some tips for making sure you and your team are operating from the same base knowledge and set of assumptions.

Don’t assume.  Even if you think that everyone knows the priorities, has been looking at the same data or been privy to the same conversations, don’t assume that the team has shared context.  Leaving it to each person to interpret conversations, make sense of data and draw their own conclusions inherently leads to misalignment and lack of buy-in regarding decisions.  Not surprisingly, as teams begin to work, the absence of shared context has severe costs – lost time and productivity, finger pointing and discouraged team members.

Write it down.  If you force yourself to write down the “Why” behind decisions that are being made, it will both clarify and improve your thinking.  You’ll be able to understand how others might react to the explanation of why and what issues they may have.  Sharing that written explanation of why with your team will allow all of you to have a common language with which to talk about problems, solutions and goals.  It will also provide a reference document that can be used by the team after the why has been discussed and you’re all no longer in the same room.

Repeat early and often.  The why is not something to be shared once and then be forgotten.  Talking about why at the very earliest points of product development lays the foundation for close collaboration and tight alignment.  Repeating the why during each step of the development process ensures that the team continues to have a common understanding and shared goals and allows the group to reaffirm or change the why as new data, requests and issues emerge.

Seek understanding, not agreement.  Assuming it’s clear that you’re the “decider” and that you’ve already gathered input from the team, the purpose of sharing the why is to help everyone understand the reasons for the decisions that are being made, not to have everyone agree that those are the right decisions.  That said, team members need to feel that their points of view were incorporated into the thinking that led to the why (writing it down helps provide evidence of being heard!).  The right outcome is to have a collaboration amongst team members based on shared context, not to be consensus-driven.

While establishing the why is critical in product development, it’s an equally important behavior in nearly all professional and personal contexts.  Next time you’re working on a project with your team, friends or spouse think about whether there is shared context and how setting that context might help you work together more effectively.

We are Product Managers

Posted on by

When I joined Twitter, one of my key responsibilities was building the product management organization to keep pace with the growth of our engineering and design teams and to lay the foundation for scalable product development going forward.  In less than a year, we more than tripled the size of the team (total company headcount grew even faster).  As you might expect with that kind of employee growth, there were many questions about how various functions should work together, especially the product development-oriented functions of engineering, design and product management.  At Twitter, we evangelized an operating model where project teams were constructed with product, engineering and design leads, each representing three equal legs of the product development stool (with other functions also providing input and feedback throughout the development process).  However, as the teams began working under this model, it became clear that each function was struggling with defining its role relative to the roles of other functions.  Who should be involved in what conversations?  Where were the lines drawn?  Who was the “decider”?  And like many companies, we were faced with the oft-asked existential questions of “Is product management needed?” and “What role does product management play in product development?”

Given all of these questions, my product team needed a reminder about why they were all there as individuals and as a product management function.  Fortunately, the web offers many excellent write-ups and conversations about what it means to be a great product manager.  But I also wanted to share my personal views on product management, developed through years of product success and failure, particularly because I believe that product management is more an attitude than a set of skills.

Below is the description of the product manager’s mentality that I shared with the team at Twitter.  I was told that it proved helpful to many of them (hopefully it still is!) as they worked with their engineering and design peers and I’m hopeful that it will be equally useful to product people (current and aspiring) who are trying to do the difficult but incredibly gratifying job of product management.  In one way or another, it’s a job I’ll always have and love.

—

As Product Managers, we are the CEOs of our products.  We love products.  We focus first on delivering value to our users.  We know who we are building for and what we are building.  We know why we are building it and where we are building to long term.  We communicate the who, what, why and where clearly, concisely and frequently.  We communicate with anyone and everyone who is interested, but most importantly to our teams.  We let our teams determine how to build.

We pursue excellence by thinking bigger and bolder than is comfortable.  We don’t settle for good enough.  We choose right over easy.  We choose simplicity over complexity.  We don’t make excuses.  We take responsibility.  We are tirelessly curious.  We respect our competitors, not fear them.  We understand why we win and what we must do to keep winning.

We lead by example.  We succeed by making others successful.  We listen first and make certain that others feel that they’ve been heard.  We pursue diverse opinions.  We rally our teams behind a vision that yields passion and commitment.  We value and foster strong team relationships.

We are determined and positive.  We use words and take actions that embody a can-do attitude.  We trust others to do their jobs well but we verify that they are done right.  We are honest, direct and empathetic.  We adjust to our audiences and situations.  We are decisive when needed, but always collaborative.

We know the definition of success.  We hold ourselves and our teams accountable to it.  We set the bar high.  We provide focus through prioritization.  We increase quality through iteration.  We don’t like surprises, so we prepare for them.  We pay attention to the details because we care.  We fill in the gaps and do whatever it takes to get the job done.  We don’t wait to be told what to do.  We leverage data but aren’t slaves to it.  We are honest.  We seek the truth.

We take time to reflect.  We don’t fear failure.  We strive to improve.

We are Product Managers.

—

Thanks to Hunter Walk and Josh Elman for reading drafts of this post.

Tips for product management success

Posted on by

I work with several early stage companies that are spending all of their time and energy focused on building great products that address real customerpain. To me, this is the most exciting time in a startup’s development. Starting from a blank page and creating something that will hopefully be in the hands of many satisfied users is both an imposing and thrilling challenge. My product management experience has given me several key insights (I think!) into what contributes to the success of a product manager. I’ll share a couple of those thoughts below and hopefully publish additional ideas over time.

I don’t think that you can be truly successful as a product manager if you haven’t experienced the customer or user’s pain firsthand.  Being close to the customer can provide unique insight into product requirements, and even more importantly, can shed light on what is not required in the product at all. Often times, customers and users will say that they want X or Y feature, but that is only what they think they want. What they need is a specific problem to be solved. Having lived with that problem can provide a product manager with the insight required to identify a true solution. All customer and user feedback is not created equal and knowing which feedback to incorporate into product plans is a necessary skill for any product manager.

A successful product manager also knows that he or she is not an engineer. Trust the engineers to do what they do and involve them early and often in product thinking. If the product manager and the management team have hired strong developers, technical leads, etc., they will not only figure out how to build the product correctly but they will help make the end product markedly better. Many product managers don’t have the confidence in themselves or in engineering to avoid micro-managing and over-documenting. But I’ve found that allowing the engineering team members to own what they are expert in leads to greater confidence in the product manager, more collaborative teams and more efficient product development. It also just makes being a product manager a lot easier!

(Thanks to Hiten Shah from KISSmetrics for inspiring this post.)