Pages

Influence without Authority - it's one of the hardest things about being a Product Manager. Recently, Martin Erikkson wrote a blog post titled "Product Managers are not the CEO of anything". I loved this post because I am a firm believer in that statement and many of the other statements in the post itself. You can find the post on Mind the Product (it provides great content).

Product managers have to lead the teams they work with, not mandate that teams do the work they say. A good product manager engages with individuals at all levels of the organization, consistently getting buy-in about product features and functionality. In his post, Martin writes "Truly successful product leaders... embrace their lack of authority and lead their teams... through communication, vision and influence." By focusing on collaboration, a good PM can bring a team together and work with them to build a successful feature or product.

The ability to influence others is no small feat. There are many personalities and opinions, and there's no way to make everyone happy. What is important is that a PM can synthesize all of this feedback, recognize others for the information they've provided and come up with a recommendation based on data-backed information. Here are some ways you can get more buy-in and build yourself as a leader:

Be the SME

Talk to your customers. Why did they buy? How are they using your product? What is the landscape of the market? Who are your competitors? If you can educate your internal team about this information, you stand to become the subject matter expert on the customer and build a ton of credibility in the process.

Create internal partnerships

It's okay if you don't jive with everyone you work with - it happens. Find a few executives, engineers and key sales people that you can build an alliance with. Support them, get to know them and be sincere. When it comes to something work related, it'll be easier to get them on your side since you've built a relationship.

Own it

Be confident and certain, and be willing to admit when you might be wrong. Accountability goes a long way when it comes to leadership and influencing others. People are looking for a leader and they want one that is strong and confident. Step into that role and put others at ease

Fake it 'til you make it

If all else fails, decide that you're going to jump into the role head first. You're not just a product manager but a product leader.

Product Management is all about two things - pattern recognition and the art of managing a lot of lists (more on this later). Identifying common problems your customers are having comes from recognizing patterns in customer behavior, business objectives and internal/external feedback. This is how I've managed to identify and validate customer problems...

1. Listen to your customers
The first step to understanding your customers is to talk to them. I can't tell you how many product managers I interview that can't tell me the last time they've talked to a customer. In my career, I've managed to speak to a customer almost every single day. Whether it was a consumer that purchased on a site or it was a business user (or buyer) to understand their pain points, I made sure I got someone on the phone or in person that could tell me how they were using our product and why.

Customer development is key to this process. Frequent interactions and iterations with potential or prospective customers help you and your team build the best products. A way that you can do this is by GETTING OUT OF THE BUILDING. Early in my career, I got advice from the team at Pragmatic Marketing - NIHITO. It stands for 'Nothing Interesting Happens In The Office'. Basically - get out of the building, talk to people. Even if you walk around the office to talk to your peers and co-workers, it gives you perspective to understand the landscape of the ecosystem you're working in. A way you can develop customer insights is by answering 6 questions:

Who are my users?

Are they businesses? Consumers? Parents? What are their demographics?

What are their habits?

Are they already doing something in a different way?

Do they create content? Share content? Are they active or passive users?

Where are they accessing from?

Where do they spend most of their time? Desktop, tablet mobile?

When do they need my product?

Time of day? During a particular moment in their life?

Why do they need my product?

Do other products not meet their needs? Do other that exist fit their needs?

How do they access my product?

One time download? Web app? iPhone app?

2. Come up with a hypothesis
Once we understand our customers, we can start to form hypothesis about our ideas. Remember 5th grade science? A hypothesis is a supposition or proposed explanation made on the basis of limited evidence as a starting point for further investigation.
A few examples of hypothesis, taken from a few popular companies:

Groupon - businesses will be willing to give large discounts for short periods of time in order to get a large number of new customers

Uber - customers will take frequent trips if it is easy to book a ride and simple to pay

Dropbox - users are willing to pay for on-demand flexible cloud storage of their files

Hypothesis statements help product teams get answers. Many digitial practices bring back the hypothesis as a way to validate prototypes and tests. Defining this up front helps the team (and the PM) strategically consider success factors and hold themselves accountable. Here's the format I've seen (and use):

We believe {this specific customer}

needs a better way to {meet this need}

because of {this insight}.

We believe that if we help them solve this problem, we will achieve {this business objective}

We know we're right when we see the following feedback from the market: {qualitative feedback and/or quantitative KPI change}

3. Validate your hypothesis
In order to validate your hypothesis, you have to ask yourself a few questions.

How painful is the problem?

How many people have this problem?

What resources are required in order to solve this problem

You can use various forms of MVP's (minimum viable products) to help validate these! I'll cover this in another post.

How are you identifying problems your users are having? How do you validate them?

User stories are the currency with which Product Managers communicate and sell the business idea they are advocating for. They are one of the most important artifacts (other than the Product Roadmap) that a Product Manager creates. Here's some suggestions for crafting user stories:1. Follow the basic formatThe basic format of a user story is:

As a {type of user}

I want to {goal}

So that I can {reason}

User stories help to answer three questions:

Who is this funcationality for?

What should we create?

Why is it valuable to the user?

Too often, I read user stories that don't include a good reason. Think about it - for your last 5 user stories, did you have a good reason for why this was important? This is critical because it helps your development team understand why they are building this.2. Include your acceptance criteriaAcceptance criteria are hard to define. I set the expectation that I can complete 80-90% of the acceptance criteria without the help of my developers, and I expect my development teams to help craft the last 10-20%. This allows room to add AC to accommodate for any technical issues or existing architecture challenges. Some people follow a formal format; I tend to fill them out ad-hoc. You can try this format:

Given {context} and{more context}

when {event}

then {outcome} and{another outcome}

3. A few best practicesA common problem among agile teams is that user stories are too big, which makes them hard to understand, estimate and implement. Keep the stories small so they can be incrementally released. A good rule of thumb is for user stories at the top of the product backlog to be sized such that the team could complete 4-6 stories a week.

To help you achieve success...

define the what not that how

use understandable language

group user stories by themes

don't be the bottleneck on your team; have a healthy backlog of user stories

A bit more about acceptance criteria

typically written at the same time as a user story

vary in number

tests if the functionality meets the expectations before release

includes both what the feature should do and the error states (most PM's forget this!)

should include design, and possible reference wireframes

How are you at writing user stories? Do you follow a different format? What advice do you have for other Product Managers?

As a Product Manager, you have to work through prioritization at various levels of the organization.

I've done this in two ways: the MoSCoW Method and the Stack Rank method. Ultimately there are two major factors that influence whether or not something should be prioritized:

Customer Value: How much more satisfied will our customers be with our product if they are given access to this feature?

Level of Effort (LOE): What resources are required to build this feature?

LOE should factor in everything from time needed to write requirements, create designs, complete engineering, test, and rollout the feature to users.

It’s very hard to put a good 'level of effort' on a project. Usually it’s just a high level estimate. The Product Manager needs to be able to clearly articulate the criteria used for prioritization to the product team and stakeholders. Product Managers frequently have to inform stakeholders that their requests for the product will not implemented. Having a clear prioritization method allows others to understand how decisions are made and earns trust that they are made fairly, logically, and in the best interest of the customer and organization.
Let's take a detailed look at the two methods:

MoSCoW Method: Rank features by classifying them as MUST, SHOULD, COULD, or WON’T, respective to whether they should be included in an upcoming product release.

Must: In order to be classified as “must”, the feature must be absolutely essential to provide value to customers. This should be reserved for top-priority features, or features that have downstream dependencies (future features cannot be built until this one is completed).

Should: These are high-value features that will bring considerable value to the product, but not absolutely essential for the upcoming iteration.

Could: These are the “nice-to-have” features. They improve the product in a meaningful, but non-essential way. “Could” features are typically not appropriate for inclusion in a MVP, but may be prioritized once a product has achieved Product-Market Fit.

Won’t: The feature will not be considered at this time. Won’t is a very useful classification for Product Managers, as it sets an extremely clear expectation to stakeholders that it is not a priority.

Remember: these classifications are not permanent. Something that is “Won’t” now could become “Must” in the future as priorities evolve.

Prioritization Matrix (aka “Stack Rank”)
The Prioritization Matrix method allows us to factor Customer Value by Level of Effort, and find the features that deliver the highest value at the lowest cost.

When building the matrix, each feature is given two scores:

Customer Value: Scale of 1-5, 1 is the least value, 5 is the highest value.

Level of Effort: Scale of 1-5, opposite ranking. 1 is most effort 5 is least effort.

Multiply the two scores together to get a composite score; the highest composite is a top priority feature.

NOTE: If you have a large set of features, it may be useful to score on a 1-10 scale to create more separation between features.

Product Managers wear many different hats - project managers, designers, strategic advisors, developers - all for the sake of being the voice of the customer. No two days are alike for a Product Manager (although with the introduction of the Product Owner role with Agile, the days can sometimes feel like they have the same structure). Sometimes she is meeting with the CEO to discuss where the company is going, other times she is meeting with sales to understand the latest crazy request that came through, and some days she is meeting with the development team to write user stories and prioritize.
Without Product Management, some truly devastating things can happen in an organization. I've shared the comic strip before, it's one of my favorites. Without Product Management, your company runs the risk of building products that customers don't want and event worse, don't solve the real problem. Think of Segway and Blu-Ray technologies - great products, very innovative, but there wasn't a problem that either of them solved. Both of those products quickly got replaced with other entrants into the market that addressed a challenge for their user.

The best example I've seen to describe Product Management is the Venn Diagram. In this, it puts PM at the center of User Experience (or UX), Technology and Business. The role really is a mix of all three. The PM has to answer three questions - What does our solution do? What is the economic impact? How do people experience it? Sitting at the center of these three areas asking these questions is where PM's can have a huge impact on the business.

Some people have said 'product managers are like mini-CEO's'. The more time I spend in Product Management, the more I could not disagree with this statement. I'll cover this in an upcoming post, but if I were the CEO for my product line, I'd be able to make decisions and rule with an 'iron fist'. As a Product Manager, you typically don't have that much power and need to work with your team to justify why the problem you've chosen is the one the development team will address next.

All said and done, there's really nothing that relates to business that product managers don't get involved in. In simple terms a PRODUCT manager is responsible for the overall success of a product from its birth to its burial; the product lifecycle. "This position is at the intersection from where founder strategy, user feedback, development team management, and market awareness come together. From what’s been said, it certainly appears that this is not a role that you “fall” into, but rather could aspire to be in." - Ken Yeung