Lizzy Masotta

There are 2 exercises I use to evaluate bringing differentiation into the products I'm building.

1. What sucks?
2. User value mapping

Where they originated

I came up with these frameworks in collaboration with Paul Pedrazzi (SVP, Salesforce) while we were working on a 0 → 1 product for small business. We repeatedly re-visited the artifacts of these exercises throughout the product development lifecycle.

What sucks?

What the outcome will be

A list of the Top 3 issues for your target user.

How to do it

1. It’s as simple and cathartic as it sounds: get in a room with a diverse group of stakeholders – Product Marketing, Support, Engineering, Sales, Product, Design, Solution Engineering, etc. You should not have more than 10 people participating.
2. Have everyone individually brainstorm on sticky notes (or a Google Jam Board) “What sucks about _____?” In the Salesforce example, we brainstormed, “what sucks about being a small business owner”? In my current role at Shopify, I lead Product for Checkout. Our prompt would be “what sucks about checking out online?”
3. Share 4 things with your group before they begin writing stickies (1) Remind them to put themselves in the shoes of the user (2) Share snippets from customers you’ve spoken to recently to get the juices flowing (3) Share an overview of the range of personas and industries you cover (4) Think big and broadly; do not think about specific issues created by our existing product or company.
   In the Salesforce example of “what sucks about being a small business owner” our stickies ranged from ‘finding new business’ to ‘not being able to take vacation easily’.
4. Once everyone has created at least 5 stickies, begin a grouping exercise. Groups should be created based on similar dimensions and each group should be given a name. An example group could be ‘getting started’ or ‘finding new business.’ Seeing the quantity of stickies per group gives you a general sense of where the problems live. Groupings will also show you things like where other competitors are focused and where there are gaps in the market.
5. Once groups are finalized, give each person in the group 3 votes. The 3 votes are used to mark what each person believes to be the 3 most important and impactful issues from the user’s POV. Votes can be cast by putting a dot next to a specific sticky.
6. Bubble up the stickies with the most dots next to them. Facilitate a conversation around where the group thinks we could focus to have the most success in differentiation and providing user value. Example question prompts:
   -Which sticky is our company best positioned to deliver value against?
   -Where do we have the expertise to deliver value against?
   -What issue would users expect us to solve for them?
   -Where is there the least competition?
   -Where is there the most competition?
   -What issue, if solved, would be the most compelling to attract new business?
   -What issue, if solved, would be the most compelling for users to stick around?

User value mapping

You can do this exercise in conjunction with ‘What Sucks?’ or own its own.

What the outcome will be

A map of the most valuable, most unmet needs in the market. This can serve as your menu of options for where to focus on differentiating your product.

How to do it

Choose a grouping from the “What Sucks?” exercise. For example, ‘Finding New Business.’ If you’re doing this exercise on its own, select a ‘Job to Be Done’ category.

1. Create a Kanban board in your tool of choice (Miro, Trello)
2. The column headers should be steps in the user journey for that category (ex: ‘Finding New Business’ or ‘Checking Out Online’)
3. The cards within each column should be desired outcomes for that step in the user journey (ex: ‘Successful purchase’)
4. Cards within each column should be ordered based on highest priority to lowest priority. Priority as defined as what is the most valuable to the user.
5. Cards should be color coded either red, yellow or green based on how unmet / met this need is in the market today. Red = no one in the market is solving this today. Yellow = some competitors address this. Green = Lots of people address this need today.
6. At the end of the exercise, find the top 5 cards. These areas should be the highest in their column and color coded red or yellow. This is your biggest area of opportunity for differentiation.

Closing thoughts

Many teams do some version of these exercises early on in the product development lifecycle and then forget about them as they’re building the product. Timelines get tight, resources get shuffled and often the scope that can get cut is the differentiation you aimed to achieve.

Every Product Manager should call out and protect differentiation. It doesn’t need to be available in the first release of your product, but you should always be working towards some differentiation that can help you acquire new customers, a new market or retain existing customers.

I love this question. Through my work at both Salesforce and Shopify this is something that comes up regularly because of our platform and healthy partner ecosystem. 

1. Do the majority of my users need this?
2. Are there problems with the partner meeting the needs of users today?
3. Do we have the expertise and staffing to build this?
4. Would building this natively unlock new value, new opportunity or a new market?

If the answers to questions 1-3 are yes, then it warrants a discussion with your team. The key question that decides the outcome here is #4. 

Is it worthwhile for you to invest time and resources into building this thing? Does it unlock new value or strategic advantage that you do not have by offering this through a partner?

Work in the open. Create a culture on your team that encourages sharing unfinished work and working live together. This will drive the highest quality bar for your team. If you wait until the end of development to QA too many problems will be compounded.

Some rituals I use to encourage a high quality b ar throughout the entire product development lifecycle:

1. Fresh Eyes - Once a week anyone in the Product Squad can demo unfinished work for the purpose of getting feedback mid-build. The phrase and concept of “Fresh Eyes” comes from Shopify - it’s part of their culture to value feedback throughout development and actively seek it.
2. Weekly Demos - Every Friday anyone in the Product Squad can demo near complete work (PM, UX, Eng, Data). The purpose here is to celebrate progress and create a shared understanding of what the product will be. There can be great feedback that comes in these sessions, but typically more minor edits around design elements (padding, text, etc) vs fundamental functionality changes.
3. Journey Checking - All too often, I’ve seen great product visions and phenomenal products not live up to the dream. When work gets broken up into bits and pieces for engineering you easily lose sight of the journeys. It is the job of the PM to define and educate the group on the key personas and journeys they will take in the product. In the weekly demos, the PM should choose one journey every week to show where you’re at with it. Individual bits may work in isolated demos, but when you string a journey together you will quickly find a lot more gaps and issues.
4. Prototype as Requirements - The UX prototype is a living, breathing requirements document that provides incredible detail beyond what a written doc could. This is the bar that is referenced and should be actively referenced by eng as they’re building. Things that cannot easily be seen in a prototype should be written as requirements by PM.

There are 2 main types of interviews for Product Management roles:

1. Product case interviews
2. Behavioral interviews (by cross functional partners like UX or Engineering, or by the hiring manager)

With either interview type, the surest path to failure is when a candidate shows up and waits to be asked questions. A one-way dialogue doesn’t expose enough about a candidate to make a strong impression. Engaging in an interactive, two-way dialogue helps the interviewer get to know what it would be like to work with you – it exposes how you think and communicate in a real world context.

The most impressive interviews I’ve conducted are ones when a candidate can interweave their experiences throughout the conversation and have a two-way conversation with me.

The purpose of an interview for the candidate is to tell their story, share their product learnings, and expose who they are in order for the interviewer to assess their candidacy.

The purpose of an interview for the interviewer is to assess if the candidate is qualified for the job and if they would be successful in the role. You make the interviewer's job much easier the more you open up and engage. And, the more you engage, the more memorable this interview will be for the interviewer when they have to write up their recommendation and discuss it in a meeting with the other interviewers weeks later.

To avoid this common pitfall, you can do two things:

1. Put yourself in the shoes of your interviewer
2. Come up with a list of 2-3 things you want to make sure the interviewer knows about you

For #1 - Who is your interviewer? What role do they have? What do they care about? If you had to guess - what are they trying to get out of this interview? Use these insights to better connect with them live.

For #2 - How does your current work connect to the work of the role you’re interviewing for? What success have you had that you want to make sure is known?

To answer this question, I’m going to put my PM hat on. Why is the engineer “rogue”? What is driving them to want to “slip in this feature”? 

1. First, I’d talk to them, understand their frustrations, and where they’re coming from.
2. From that conversation, I would expect to learn a bunch of stuff I probably didn’t realize about how frustrating it is to build in our codebase. The engineers and designers on your team are a key persona you must also serve as a PM. If you can make their lives better, easier, more efficient – do it.
3. Then, I'd come up with a plan to make sure we allocate a portion of our development efforts to internal improvments. The best execution I’ve seen around making non-customer facing improvements is an approach Salesforce used called the “Trust rotation.” Each sprint 1 engineer was dedicated to “Trust.” There was a “Trust Backlog” the team maintained, prioritized and agreed upon. And, any other burning sev0 issues would go to this eng too.

Engineers are part of your squad. They should be in the room for Problem Shaping, Live Prototyping, and Fresh Eyes. You should review your problem backlog regularly with your engineers and get their input and feedback.

—Influence is the curiosity to get to the best solution— and engineers will undoubtedly think about things differently than you - leverage this to find the biggest problems and get to the best solutions.

More about influence here: https://medium.com/@lizzymasotta/product-management-is-not-about-influence-e3004c12f44f

It is the Product Manager’s job to identify, prioritize and shape the problems the team is tackling. We’ll break this into two parts 1) finding problems 2) shaping problems.

Finding Problems

You need to have ongoing sources that you’re plugged into to find problems. Common sources are 1) customer research 2) exec requests 3) support tickets or user feedback 4) product usage data.

In my experience, I’ve found the most fruitful source of problems and opportunities is customer research. Be careful with exec requests - the common behavior is to blindly execute on them. You must ask questions. Where did this idea come from? Why do they think it’s important? Support tickets tend to be a gold mine for problems, but typically more miniscule ones. It’s important here to find greater trends and patterns that point to bigger problems. And finally, data is a great signal, but tends to require interacting with the user to understand the broader problem at play. Follow up on the signals you see in data with talking to users.

Prioritizing Problems

This should be done transparently with your Product Squad (ie UX, Eng, Data). Each week you should review the prioritized backlog of problems you’re shaping (actively researching and defining). Your squad should provide their feedback and input on the problem backlog (add / edit / remove items) and align on the prioritization.

Shaping Problems

Before the squad can work on a problem together it needs to be shaped (ie talk to customers, dig into the product, look at data and answer these 7 questions below):

1. Why is it a problem?
2. Who is it a problem for?
3. When does it happen?
4. What does the current (broken state) journey look like?
5. What workarounds or hacks are used today?
6. How many customers is this impacting today?
7. Is this a problem worth solving? Why?

A shaped problem should always have a 1-pager that concisely summarizes the answers to the above questions. At the start of each sprint, the PM picks a shaped problem from the top of the backlog to focus on. This is when Discovery and Prototyping begins.

I don’t believe in a universal end-to-end product development process. I believe there are key rituals and elements that should be present on every team to ensure great outcomes, but each team needs to tailor the development process to their unique situation.

My must-have product development elements & rituals:

1. Common Language - Your company should have a common language for the product development process. This is not a prescribed way to do product development for every team at the company (this needs to vary team by team for good reason).
   At Shopify, we call it GSD (get sh*t done). The base elements are a common language around Product Development stages: 1) Proposal 2) Prototype 3) Build. We have an internal system at the company where you can look at all development projects and the stage that they’re in, how long they’ve been in that stage, when they’re expected to go to the next stage.
   We also have a common calendar of 6 weeks sprints that is used by the company wide. This helps when you’re having a discussion around when do you think you will have x? This transparency and common language is key.
2. “Agile Research” - This is a term I coined to describe the act of always conducting user interviews. The problem with well-designed research projects is that they take too long and tend to deliver the insights after you’ve started building the thing. Advocate for a “rolling recruit” of your key personas so that you can tap into talking to users *every week.* This ensures you have feedback and insight in the moment you need it most before the product is built and decisions are made. Alternatively, you can create a type of Customer Advisory Board where members opt into research questions, providing feedback, etc on an ongoing basis.
3. Continuous Product Discovery - A common misconception around PMs is once a project is kicked off and being prototyped their discovery work is done. Discovery is a never-ending job. There is a lot of work to be done up front to define the problem and opportunity more broadly, but throughout the development lifecycle there are endless sub-problems that need to be found, defined and shaped.
4. Unstructured Live time with the Product Squad - At Shopify, we refer to this as "Jamming." This is the schedule I tend to implement on my teams:
   Monday - Problem Shaping, Wednesday - Live Prototyping, Thursday - Fresh Eyes, Friday - Demo. Monday and Wednesday sessions are unstructured live time with the Product Squad. PM, Eng, UX, and Data get on a call and stare at the Problem or Prototype together. PM guides the Problem Shaping meeting and UX guides the Live Prototyping meeting, but the purpose is to tap into all the brains on the team to get to the best outcomes. It can be terrifying for a lot of people. It’s like getting in the car without a destination in mind. You need to create a culture on your team where it’s ok to not have all the answers. To prepare, the PM can have “intended outcomes”, “problem definition” or “options” prepared. During the meeting, the PM facilitates getting insights from the group around what else to consider, what’s missing, etc.
5. Progress every week - Another cultural thing - you need to have rituals on your team to encourage and ensure progress is made in some way, shape or form every week. My favorite way to do this is the weekly demo AND ensure that not only eng presents, but also folks from PM, UX, etc.

The most common mistake is to not think about it at all.

It can be so challenging to get a product built and shipped at your company that Product Managers naturally become very internally focused. They have dependencies to manage across other teams, they have timeline pressure from leadership, there are technical challenges to work around, etc.

On top of it all, most Product Managers don’t engage their Product Marketing counterpart until they are almost done building the thing. This should be avoided at all costs – your Product Marketing partner is key in helping guide and shape creating the best product that will land most favorably with your audience.

Start by analyzing why this might be happening. It’s a key signal that shouldn’t be ignored, and needs further digging to understand what’s behind it.

Is there a misperception of your brand? Is there a misunderstanding of the product offering? Are you missing features? Is there a lack of awareness of the company / offering?

Consider conducting interviews with users and salespeople to get a better understanding of the misperception.

If you can diagnose what exactly is behind this miscategorization, then you can start identifying who to work with and what to do to resolve it. It will almost likely require a collaboration between product marketing and product to resolve.

When I worked on a 0 → 1 product at Salesforce for small business, the challenge we faced was the market not seeing us as a viable solution for small business. This is something we needed to shift – across research firms, users, prospective users, etc. In order to make this shift we needed to have the right product that served this group's needs, and the right marketing to pair with it to get our message out.

At the end of the day, what matters most is what your users and prospective users think of you – if they’re finding your product, using it and sticking around.