What to do in your first days at a new product job

Adam recently told me that my list of product management resources helped him land his first product job. His next question was simply, “any advice for my first week?” So for Adam, and for anyone starting a new product role, here’s your first week:

  • set up weekly one-on-one (1:1) meetings with your manager, and
  • work with your manager to set goals for 30 days, 60 days, and 90 days.

The 1:1s build your relationship with your manager and make sure you’re aligned on what needs to happen for you to succeed in your new role. You want that person to see the work you do; when you’re working on intangible stuff like software, no one will “see” it until it’s completely built. So, we’re reporting back on the work that’s happening in the meantime. Illustrate the value you bring to the team.

Setting 30, 60, and 90 milestones gives you attainable and concrete “wins” that you can feed back into those 1:1s. Measurable wins are important in your “trial” period (the first 3 months at a job where you’re most likely to be cut loose if it’s not a good match.) Plus they feel great.

First 30 days:

Now, we’re going to talk to people, and figure out the issues that need solving. Spend time every day having “coffee” (over zoom these days) with folks you will be working with. Learn as much as you can about all the company’s business problems.

Dive into customer service tickets. Look for trends and learn as much as you can about the customer problems. Try to make good friends with the customer service team. Request to have the same access they have to review incoming tickets.

Note: If your team is “B2C” (business-to-consumer), your users likely contact you through a customer support team. If your company is “B2B” (business-to-business), your users may contact you through an account management team. Either way, same advice — make friends with whomever is close to the customer. Check in with them regularly about customer needs as those needs change over time.

Dig into the data as well. First, just do a high-level audit — what data do you even have? To what extent can you access and make sense of it? How much confidence do the people who’ve been there for a while seem to have in that data? Why?

Following this plan, a 30-day milestone may look like “set up regular 1:1 meetings with stakeholders from departments x, y, and z. Gap analysis of quantitative data sources. Summarize learnings in writing for the team.”

Day 30–60

So begins your second month. Research as much as you can about the Market. Look at the competitive landscape from a business point of view. Look for places where business needs and customer needs overlap. You’ll usually be able to find a few. Focus on ones that are within your resources and core competencies to act on.

Talk to customers and potential customers. Learn as much as you can about Market opportunities and gaps. Look for patterns in customer service tickets. This may reveal common user problems that you need to better understand. I tell the CS team which topics I am most interested in learning more about. I let them know that I’d love to speak to customers who reach out to us about those issues.

Sometimes customer service will CC me into an email thread. I’ll either email or set up a phone or zoom call with that customer to learn more. I use a tool called Calendly to let anyone relevant easily schedule time on my calendar. Almost everyone willing to take their time to talk to me has something to teach me — I’ve never found it to be a waste of time.

Reaching prospective customers is harder. I’ve used Survey Monkey. I’ve also posted links in relevant subreddits and Facebook groups. I’ve even posted survey links in the comments section of Youtube unboxing and how-to videos for a competitor’s product. I’ve posted in my own personal networks on Linkedin and Facebook and asked peers to connect me to people who are trying to solve for x. Any place where my potential customers and I overlap.

When conducting these user interviews, there are some best practices. I try to keep my own biases and assumptions at bay. I listen more than I speak. If the other person starts talking while I am talking, I go quiet and defer to them. I am there to learn, not to teach, even when the urge to correct a user who “isn’t using our product correctly!”. I always ask permission to record our conversations (and DO ASK FIRST, a lot of states legally require it and it’s just the right thing to do). I use two tools — Temi and Otter.ai — to get voice-to-text translations. A lot of bias is introduced in note-taking; transcripts reduce that bias.

It’s wonderful to be able to give the rest of the team quotes in our customers’ own words. Direct customer quotes can often serve as objective criteria when your team disagrees.

If you’re not sure what to ask customers, have some conversation starters:

  • What is your main goal?
  • What’s your biggest barrier to accomplishing that goal?
  • How do you currently work around that barrier?
  • What about this keeps you up at night?

Interviews and surveys are qualitative data, but you may also have identified some quantitative data gaps. Make friends with anyone who can get this data and help you understand it. If the data just isn’t being stored, what’s the quickest way to start storing it, even if it’s not perfect? Can your engineers add a Google Analytics pixel so you can start tracking default events? Can they update a few button links to bit.ly links so that you can approximate conversion data?

Your 60-day goal might look like:

  • Conduct 15 customer interviews.
  • Summarize findings and key takeaways to share with the team.
  • Work with engineering to start collecting data we’ll need to measure success.
  • Schedule lunch with Jim in marketing to learn about competitive landscape.”

Day 60–90

Your Q1 on the job. It’s time to start selling your vision of the future. Have many [Covid-Compliant-while-it-lasts] coffee conversations. Talk to people about where you see the company in another quarter, a year, even 5 years. What can feasibly be built to help current customers, attract new customers, and move the business forward? See how they respond. Where do you agree? Do they have a different vision of the future?

In each conversation — with your manager, your peers, and your customers — listen more than you speak. Be open to constructive criticism and new information. Invite others in to be a part of building great new things with you. We are all stronger together, and your vision will be stronger if it’s shared.

Don’t assume anyone else is having these conversations. Connect like-minded peers and see which ideas flourish and gain momentum. Build your own cross-departmental “idea” team. Take the ideas from these conversations and build a roadmap to share with everyone.

Your 90-day goal might look like:

  • Work with engineering to understand the level-of-effort to address key use cases.
  • Identify MVP experiments and tests to de-risk higher effort items.
  • Draft product roadmap for internal review.

Delivering on your 30, 60, 90 day plan

Here is a hypothetical 30, 60, 90 day plan for your first quarter:

30 days

  • Set up regular 1:1 meetings with stakeholders from departments x, y, and z.
  • Gap analysis of quantitative data sources. Summarize learnings in writing for the team.

60 days

  • Conduct 15 customer interviews. Summarize findings and key takeaways to share with the team.
  • Work with engineering to start collecting data we’ll need to measure impact.
  • Schedule lunch with Jim in marketing to learn about the competitive landscape.

90 days

  • Work with engineering to understand the level-of-effort to address key use cases.
  • Identify MVP experiments and tests to de-risk higher effort items.
  • Draft product roadmap for internal review.

Creating and following a plan like this will set you up for success and ensure you have the knowledge, connections, and buy-in you need to make impactful change at your new job. Good luck!


If you’re interested in getting more product principles in your inbox, sign up!

Processing…
Success! You're on the list.

Business strategy lessons from an 8-year-old amputee

Anna’s* leg was amputated when she was 8 years old. Her earliest memories are of nurses, cold white halls, and fear. Anna and her family spent several years fighting an uphill battle, uncertain if they could win. 

At 7 years old, Anna was brought into a room with a doctor to discuss for the first time the cancer she’d already had for many years. He showed her backlit images of tumors that had been removed and tumors that had grown in their place. The doctor painted a bleak picture of a body that was too fragile to keep up with a vicious blight that just kept coming back.

But to Anna, his conclusions seemed incongruous with the data laid out before her. “You’re only showing me pictures of my leg.” The adults sighed, and began to explain from the beginning. She insisted on more data. Quickly, her fresh perspective had spotted a — possibly fatal — flaw in her medical team’s strategy.

In the weeks after, Anna insisted: “I would like to amputate my leg.” Her whole life, she had thought she was dying, but when she understood the root cause of the issues, she realized that she was actually perfectly healthy, it was simply her one leg that wasn’t well and was holding the rest of her back. To her, the strategy was simple — amputate the leg, amputate the problem. She’d be able to leave the hospital, go to school, have friends, and live a much more fulfilling life as a healthy person with one leg than a dying person with two.

A few days before Anna’s 8th birthday, her strategic plan was implemented. It was terrifying and painful, but it worked. Her sick leg was amputated, and her cancer was suddenly gone. She woke up from surgery with a completely new future of opportunities. The cancer never returned and Anna is now a happy, and perfectly healthy, person. She has a huge laugh, and wears short skirts to show off the bright gold, thin metal rods that runs from her hip joint to the ground. It looks awesome.

In business, 7 years is too long to wait to re-evaluate your data and action plan. Unlike Anna, your business may not survive. 

The pivotal reframe here was one of identity. As soon as Anna identified herself as separate from her leg, her best path forward came into focus. Given the same data, a child with dreams of becoming a gymnast may not have made the same choice, and that’s okay. Who we are is what guides us forward when faced with devastating data. In business, that identity is made of our vision of the future, the mission that drives us, and the principles to which we’ve committed. Those three inputs become our framework for focusing data into a plan of action. 

* Name and details changed, just in case there’s more than one person rocking a gilded appendage. Shared with permission.


Processing…
Success! You're on the list.

Introducing the GRIDS framework: take the guesswork out of building product roadmaps

A roadmap is a tactical plan for executing your business strategy. The roadmap should clearly communicate how you will build products that deliver predictable business impact. 

Note that I’m saying “how you will,” not “how you can.” There are infinite things you can build. But a good roadmap, and a good product team, will focus on the most impactful opportunities. These opportunities solve a significant unmet user need, are viable and feasible, and align with your vision, mission, and core values.

A good product roadmap should:

  • be useful for the whole organization
  • be human-readable
  • evolve in response to external change
  • clearly communicate quantifiable impact
  • clearly communicate quantifiable risk
  • fit on one page

A roadmap is also a promise. You are promising that you’ve done your homework and identified the best possible opportunities, and you are committing to move quickly enough to seize these opportunities before they expire. You are also promising the opportunities that you decided against including in the roadmap will not distract you from these focused goals.

If that sounds like a tall order, it is. Creating these kinds of roadmaps is a science, not an art.

The GRIDS Framework

This series proposes a framework for generating a product roadmap that represents the few focused opportunities that can provide real impact to your business.

This framework starts at the strategy level and explains how to distill, from many opportunities, the ones that are right to pursue. We’ll also discuss tools for saying no to the wrong opportunities. Rather than a prioritization framework, this is a decision-making framework that can help you choose, communicate, and commit to impactful work.

The first letter of each of each step in this distillation process happens to spell “GRIDS,” so I’m calling this the GRIDS framework:

  1. Gather & group
  2. Review & respond
  3. Investigate
  4. Decide
  5. Share

Step 1: Group like ideas

Group ideas that are similar in scope or spirit first. Take note of duplicates, as this might be a signal that there’s a significant unmet opportunity. 

Step 2: Review & respond

This is an initial triage to sort out ideas that are in conflict with any of your filters. If you’re unsure, pass that item into the next step. It’s important that your product team have a confident, documented understanding of each of these filters:

  • Business strategy
  • Mission &
  • Vision, &
  • Core Values
  • Customer need

We’ll talk about why you need each of these in-depth later. This process must be collaborative and transparent.

Step 3: Investigate

For remaining items, look for a marriage of user need and business value. This is where opportunities exist. Evaluate the size of the opportunity and the scope of the user need. Be creative. If you’re evaluating at a specific solution, peel away the tactical layer — the solution part — and look for the user pain point it’s aiming to solve. Validate that user need. Does solving that pain point generate business value for you? Understand the cost of action on these opportunities as well.

Step 4: Decide

Don‘t “prioritize.” Decide.

Step 5: Share

Publish the most impactful opportunities — the ones you’ve decided to take action on — on your roadmap. Map them according to business impact and confidence. Note that “business impact” is a variable dimension that may not be revenue.

Your roadmap should fit on one printed page, so that it’s consumable at-a-glance. This final output should be accessible to everyone in your organization.

The GRIDS framework will help you create roadmaps that succinctly communicate business impact at a glance, ensure alignment, and provide actionable direction for fast-moving teams. It also ensures the opportunities to which you commit resources are easily quantified in terms of potential value and confidence in delivering that value. Done well, everything that makes it on your roadmap will address user needs and build business value while amplifying your business strategy and staying true to your vision, mission, and core values. 

A note about inputs

This series assumes that you have more ideas, feature requests, and opportunities than you know what to do with, which is exactly why I’ve created a framework for filtering these down to a manageable, actionable list. If that isn’t the case, start with this post on divergent thinking and ideation, and then come back.


Step 1: Gather and group ideas

The first step of the GRIDS framework is to gather all of your ideas into one central place so that you can filter them. 

Gather

Let’s say you have a ticketing system where people send feature requests to the product team. These might come directly from users, or from your customer success team, or from other people in your department or on other teams, or all of the above. You might even have different systems for tracking different kinds of requests. It’s probably an overwhelming mess and some of those items are likely 3+ years old. Correct? Let’s fix that.

So let’s start by making sure we’ve gathered everything we need to triage into one single location. Then, group similar requests and ideas together.

Group

In effect, you are de-duping your data. Don’t just delete duplicates, however. Do not delete anything yet. Yes, you might already know that you aren’t going to act on some of these. Save judgment for the next step. Even if you think an idea is terrible or in-actionable, do not delete it. These ideas, even the bad ones, are data, and we don’t want to lose any data. Right now we only want to collate and de-duplicate so that we are starting with a clean list in a single location. We are not passing judgment yet. I think about this as “lossless” vs. lossy compression.

Take note of duplicates

Take note of — literally notate — repetition. If an idea has come in 8 times in the last 3 years, this may be a signal that there’s a very painful unmet need here that we should find a solution for.

Call for entries

If you or your team have ideas that aren’t listed yet, add them! We want to start with everything in one place. Whether it’s a visionary idea you’ve been brewing for a few months or feedback from a customer survey, everything you might possibly want to devote resources to needs to be pooled in one place. 

This may take a day or two, and can be a tedious process. But it’s important to clean up your inputs to make our next step easier. The output of this process is a clean list of unique ideas, with an indicator of how many times this idea has been brought up. 

The idea queue is not your product backlog

Don’t mistake this list of ideas for your product backlog. This is simply a list of unique ideas. There are more decisions that need to happen for each of these items before you decide whether or not it’s actually going to become a part of your product backlog. This is an important distinction, because your product backlog is part of your roadmap, and remember — the roadmap is a promise. Items on your backlog are the opportunities that you intend to act on that you believe will deliver business impact. And you are committing to delivering on those in time to grab the available market opportunity. We’re not there yet.

Before moving on, you can choose to publish this clean list in a place that the rest of your organization can view. “Here’s everything that our product team is about to triage” you can offer. “If you have anything to add, please do!” Showing your team that you take their ideas seriously makes people feel heard and respected. And giving people permission to offer up their ideas may uncover opportunities that wouldn’t have otherwise surfaced.

Output of Step 1:

A clean list of all unique ideas in one central place. Each is notated with the number of times this idea has come up.


Step 2: Review and respond

No matter where or from whom an idea originated, every single idea must go through triage before there’s ever a conversation about whether or not it should be on the roadmap. 

“…surveying and understanding your inputs is arguably… the most important thing that you and your team should be doing before you go ahead and plan your roadmap.”

— Sherif Mansour, Principal Product Manager, Atlassian

Review

Take the output of step 1 — your list of ideas — and review each item. I recommend doing this as a team, with voices from product, design, and development included. Sort by the ideas that were most requested to least. Do a quick sanity check to decide whether or not each idea really represents an impactful opportunity, and should pass to the next step. 

For each item, you’re going to ask yourself:

  • Does this effort align with our core values?
  • can we see a line from this request to our company vision?
  • is this effort on-mission?
  • will this effort amplify our business strategy?
  • is there a user need for the output of this effort? 

If the answer to one or more of these is a definitive “no,” put it in the reject pile. If the answer to all of these is “yes,” then this is truly an idea worth investigating.

If you aren’t sure about an idea, let it pass to the next step. Allow your stakeholders and team members to help you triage later. You’re accepting a little bit of bloat here because you’re rejecting the risk of making the wrong call. We’ll dig into those uncertain opportunities more in the next step.

This review should take no more than two minutes per idea. Don’t spend hours on one item. We’ll investigate further later. We’re not trying to quantify potential business impact here; we’re simply deciding if we should carve out time to investigate the potential impact. 

Ultimately, this step is much more about the ideas that you choose not to act on than anything else. Whatever items pass this step are now officially on your product backlog, and become the input for Step 3.

Transparency is key

There’s a wonderful video created by Harrison metal, a VC firm, that I really recommend watching if you’ve got three and a half minutes.

I found two important takeaways from this video. First, your review criteria must be consistent and should be published. So that earlier checklist — your vision, mission, core values, business strategy, and user needs — should be published and be able to be referenced by anyone in your org. (And while I haven’t gotten there yet, I’ll be publishing articles about each of these — stay tuned.)

Respond

Second, you should respond to the ideas that did not make it onto the backlog. The easiest way to do this is by publishing the reject pile. But if possible, respond directly to the original contributor to let them know why you are, or are not, moving forward with their idea. This is data that is often lost. That missing feedback loop, when decisions are made to not take action, leads to a tremendous amount of frustration for people who may have had a request or an idea that they thought was really great or very important who never see that come to fruition. It can erode their trust in your department. It can erode their willingness to work with you on other things that you may really need from them. And it also fails to give them the feedback loop of why you didn’t take action on it. And that feedback loop is a very important part of communicating to your organization what’s really important for the product team to deliver to help the business. You should clearly communicate what the product team is focusing on and what they can expect from you.

The art of saying “no”

You don’t want to go send around a company-wide email about why you decided Jim’s idea was terrible. But you may want to send a personalized message to Jim thanking him for the time it took for him to write up that feature request, letting him know that you really appreciate his willingness to contribute to your team’s success, and you look forward to working with him in the future. Then, give Jim some insight into why you decided not to move forward with his idea. This person may really appreciate that you’re giving them more information than they’ve had in the past, and they might actually be able to come back with, “well, what if we did it this way?” You may find that the revised version of this that is more in line with your product goals is actually a really great idea that should be reconsidered.

The extra step of sending this feedback does take time, and it’s tempting to skip. But I strongly recommend you invest this time in those relationships. Done respectfully and well, you can say no to stakeholders who far outrank you, and they will thank you.

A note about conflicting needs

There will always be some business needs that have no bearing, or even sometimes a negative bearing, on your customers. Legal constraints, last-mile delivery logistics, etc. Because of this, you should only filter out the subset of your request queue that you are certain do not amplify your business strategy. Remember that your business strategy always includes some degree of risk mitigation. It’s a fair question to ask yourself “Am I in any way qualified to decide whether or not we should do this?” In the cases where the answer to that is no, such as infrastructure or compliance requests, that item should always pass this review and make it into the next step.

“Everything you do should be from the perspective of meeting a customer need, and that’s critical, but it is often not sufficient. It is wonderful in theory, and usually in practice, but there are always other constraints. There are always other tradeoffs that you need to make. Business needs that need to be met, technical debt that needs to be paid off, sales quotas that need to be met. The ideal of customer-centricity is an important one, but it’s hard to meet every single time. And sometimes you need to make a “bad tradeoff” to keep the business going. And part of the role of the product manager is making those calls, making those difficult decisions, those trade-offs, because at the end of the day you want to make sure you’re still there in the long term. And what you need to ultimately land on is having a sense of where you can compromise and where you can’t. That ultimately is the toughest thing for a product manager to learn.”

— Chirag Fifadra

A note about unrealistic expectations

Is it the product team’s responsibility to assess user needs. It is also the product team’s responsibility to propose strategic initiatives that both fulfill user needs and are on-mission. It is someone else’s responsibility to set sights on a vision and propose a mission to getting there.

In reality, you will seldom have a polished business mission and vision handed to you. If your company is lacking these inputs, it becomes the product’s responsibility to propose (and generate team-wide buy-in for) a product mission and vision. Working without these is to fiddle aimlessly in the dark, and is a waste of someone else’s money, many people’s morale, and your time. To knowingly do this, without trying to bridge those gaps and get back on course, is unethical.

Output of Step 2

  • Product Backlog: the opportunities you will put your resources to creating solutions for.
  • Reject pile: non-impactful resource vampires that no one should be working on.

Step 3: Investigate

For each item in the product backlog, we’ve decided to devote time to investigating which ones are the best opportunities to take action on. You probably don’t know exactly how much business value each of these ideas could create. You probably don’t know how much this could benefit — or annoy — your users. And you definitely don’t know the cost, the full cost, of devoting resources to this opportunity. So we need to find that out.

This is what most teams would call product discovery, and people usually start this too soon. By having first reviewing our ideas, and rejecting many, we’ve already focused on the most promising opportunities, and significantly reduced the amount of time that it’s going to take us to investigate where to spend the rest of our energy. We know that every single thing that we’re investigating is something with real potential, so morale is high. Morale is a lot higher than if we felt like most of these are probably never going to see the light of day. 

Now, we investigate and learn enough to make a final call about whether each idea goes into development or gets tabled. 

Validate the user need

The first step is always to validate the user or customer need. Without customers, you’re not in business, so there is no idea that will have any business impact if it does not materially benefit your users. This is where you should spend most of your investigation effort.

Desirability

Once you’ve validated that you’re dealing with a real unmet user need, the second step is always to question whether the solution proposed is the right way to address that need. It’s usually not. Always work backward from “what is best for our users?” What will they accept, adopt, pay for, and refer? What will seem obvious to them and what would be confusing? Elegant solutions should immediately make sense for the customers you have and the customers you want. 

Feasibility

Make sure that your solution is technically feasible and financially viable. You will need your technology team to weigh in on the technical cost of building that solution. How many engineers would it take? Would you have to hire more? Does our current tech stack support this solution, or would a large refactor or re-platform have to take place to lay the necessary foundation? Does the technology even exist to do what you’re trying to do? If so, how mature is it? Can you risk building a product on unproven tech?

Viability

Does your team have in-house capabilities to deliver on this idea? Or would you need to partner with someone? Does your solution mandate new processes, or have an expensive downstream impact on other teams, like sales or customer service? Do you really have what it takes to solve this unmet need? What are the non-technical costs in goodwill, trust, etc. that you’d need to expend to gather the right resources to even start working on this solution?

Measuring impact

For each idea, we need to know how we’re going to measure success. What KPI — key performance indicator — will we use, and what change in that number do we expect to see? Remember, that number can be a range.

We’ve also hopefully identified control metrics — things we do not want to see change. We also want to be honest about our confidence level — how certain are we that we know enough about this opportunity to know if we can definitely impact our KPIs? 

If an item is really uncertain, and you have low confidence in your quantitative impact, ask yourself if it can be broken into smaller, less risky pieces to help you learn more about that unknown opportunity in smaller stages at less cost. 

“Knowledge can be seen as the opposite of risk. So when uncertainty is high, our focus is knowledge acquisition. We focus on things like user experience prototypes, technical “spikes”, or experiments.”

Agile Product Ownership in a Nutshell

The cost of delay

Opportunity is a moving target. User needs and expectations change over time. The competitive landscape changes, and what may be technically impossible today may be very feasible tomorrow.  

“The features and products that we ship have a limited half life, and the longer it takes them to get to market, the less value that they have.”

— Dave Wascha

Don’t miss your window of opportunity.

Output of Step 3:

A Product Requirements Doc, or something similar (you can call it whatever you want) that spells out the potential business and user impact, and how you’ll measure this impact. Now, you should have a clearer picture of the impact of each opportunity and the true cost of choosing one opportunity over others. From that data, you decide.


Step 4: Decide

Once you understand the desirability, feasibility, and viability of each of your options, it’s time to make decisions about where to expend limited resources to make the biggest impact on the business. It’s very important to understand that a prioritization process can assist in deciding which opportunities to chase, but it is not a decision. Prioritization helps us identify which things have the most potential; decisions help us not be distracted by everything else.

Prioritization identifies potential; decisions prevent distraction.

“A priority is observed, not manufactured or assigned. Otherwise, it’s necessarily not a priority.

Got that? You can’t “prioritize” a list of 20 tasks any more than you can “uniqueify” 20 objects by “uniqueness,” or “pregnantitze” 20 women by “pregnantness.” Each of those words means something.

An item is either unique or it is not. A woman is either pregnant or she is not. An item is either the priority or it is not.”

Mud Rooms, Red Letters, and Real Priorities

As humorous as this is, I still think the “prioritization” process is a useful tool. It’s just important to understand prioritization is just a process; decisions are the necessary output.

Prioritization frameworks

There are countless prioritization frameworks for understanding impact and cost. The skill of prioritization is understanding when to apply each of these frameworks. There are two ways of thinking about this — decision making frameworks vs. force-rank frameworks. Whichever framework you use, there are two important things to know about the prioritization process:

The first rule is that this exercise must be done collaboratively. Teams that make these decisions together are more likely to feel good about the decisions. The people who will be executing this work — your development team and design team — should be a part of this collaborative process. Now, you should still prepare for this meeting, and walk in with a recommendation and a request for feedback on that recommendation from design and development. You shouldn’t be asking them to do your job for you. But you should be open to their input, and make sure that they feel their discipline concerns have been appropriately weighed. My husband refers to this as having “strong opinions, weakly held.” Come prepared with a proposal you can defend, but be willing to change it after team input.

Second, prioritization is unique to each team and company. No framework can replace understanding your business and your resources well enough to do these calculations.  You will need to understand and take all of your unique constraints into account. Be open-minded — is this really a constraint, or just a habit? But also be grounded in reality about what you can feasibly achieve. Some business value delivered is better than no business value delivered because a project got derailed.

“A good plan violently executed now is better than a perfect plan executed next week.”

— Gen. George S. Patton

Output

Is NOT simply a prioritized list. The output is a subset of your prioritized list — the right opportunities that you have decided to focus your resources on.


Step 5: Share

The final step in this process is to plot the decisions you’ve made on a roadmap that everyone can reference. The point of a roadmap is to convey the tactical plan you will execute to meet strategic goals. You’ve decided what those tactical plans are, now we need to illustrate how they will meet our goals.

Horowitz Law

A roadmap needs to be understandable at-a-glance. People higher up than you, with different and riskier work on their plate, don’t have time to reverse engineer how you’ve put this together. It should be obvious at a glance, on one page. A best practice, that I jokingly dubbed the “Horowitz Law,” is that the roadmap should fit on one printable sheet of paper, and be readable on one slide in a presentation. No amount of long-winded explaining, previous success, or data will have the same impact on someone as that “Oh! I get it!” moment they can only realize from a well-composed, 1-page work of art that should be your roadmap. Use your data-ink ratio wisely.

Dimensions of a product roadmap

Before trying to place onto the roadmap, you should understand what a roadmap actually represents. Most roadmaps have 2 dimensions. Along these axes, you map your decisions to share with your team.

Confidence

This is the measure of how confident you are that you can deliver the business impact potential in a given opportunity. If you’re building to learn, things that are further away have more unknowns, so confidence inherently decreases over time. If appropriate, you could represent this dimension as a timeline. Most roadmaps do, but it’s important to understand that time is really just a proxy for confidence.

If it’s important to you to not commit to specific dates, you can use the headers “current,” “near-term,” and “future.” Most people use quarters (Q1, Q2, etc.) This is most appropriate for manufacturing and shipped products. In the tech world, this may be criticized for seeming “waterfall.” Know your audience. Don’t use buzz words; use the right words to communicate the important things to the right people.

Business value

This entire axis should map to an agreed-upon business strategy. I would label this axis with the type of business value you anticipate and the metric you define success for this strategy by. It’s important to remember that this success metric may not be related to revenue, depending on the stage of your company and the strategies you are employing. 

We’ve decided what to work on based on this business impact, so higher priorities go at the top.

Optional 3rd dimension — Strategic initiative

If you manage multiple products, or a complex product with many different development teams, you may need to visualize their impact across different strategic goals of your organization.  

You obviously can’t display 3 dimensions on a 2-dimensional sheet of paper or slide. Use a new page for each strategic initiative, and put the pages in priority order, first to last.

Roadmaps should also have…

  • A title! Be simple and straightforward. Let people know what they are looking at.
  • A contact name and email for the best person to reach out to if someone who is reading the roadmap has questions. This is probably you.
  • Your resource dependencies. It’s good to clarify that this plan is dependent on resources that, if altered, would impact delivery schedule and/or scope. These dependencies may include current team size, projected future team size, specialized skillsets, etc. This section should be about as long as this paragraph.

Tools

Use whatever tools are most comfortable for you. Yes, a product roadmap does get updated, but that should happen quarterly or monthly on extremely agile teams. It’s okay if it takes you a little time to translate the work you’ve done into a format that makes it easy for others to understand and appreciate that work. I usually do mine in Google Sheets and Slides. Another tool I really love is Airtable. And frankly, MVP is some sticky notes on a wall. At the end of the day, the goal is to communicate decisions to keep your team focused. Whatever tool empowers you to do that is the right tool.

Output of Step 5:

A great product roadmap that the whole team can reference!


Conclusion

Using the GRIDS Framework, you can reliably create product roadmaps that are actionable, understandable, and which represent real business opportunities. At the end of this process, the roadmap serves to document and communicate your decisions, but by the time you have it the hard work of reaching consensus is already done.

I recommend that you go through the steps in this framework at least quarterly. Ideally, I think this is a process that the product team does monthly, whether you make changes to your roadmap or not. Once a month gives you given new information in the market, new constraints, new user feedback, new ideas, and information about new resources gained or team members leaving. All of those factors may impact which opportunities are most impactful at a given time, and in feed into refining your roadmap.

Development process be damned

The GRIDS framework is completely development process agnostic. The output of this work can feed into any process, agile or not, that your development team uses to accomplish their goals.

Small details might differ, but ultimately this is a product-owned process. The output of the framework, a product roadmap, can be an input to any development process. Nothing about this should mandate that your development team change what they’re doing, for better or worse, this is not something that should cause pushback from a development team, because this does not necessitate a change on their part.

A note about success, and failure

“It is possible to commit no mistakes and still lose.”

— Captain Jean Luc Picard. Or whoever wrote that line.

I cannot guarantee that this framework ensures success. I do guarantee that it will provide objective structure for product decisions that can be more easily defended, empower you to say no to the things that are not the best use of your resources, and help you focus your efforts on impactful work. If all of those things are true and you are still not succeeding, I’d take a look at your higher-level inputs — your business strategy, vision, mission, and core values — and see if adjustments are needed. I’d also go back to your user research and make sure you’ve identified true needs and provided unbiased solutions for meeting them.  

I hope this has been helpful. Let me know if you’d like me to discuss this framework with your team. If you have questions or ideas about anything in this framework, I’d love to hear your thoughts.


Processing…
Success! You're on the list.

Product Resources

A list of educational resources curated over the last 10 years of my career in product. I’ve put authors and resources worth following in parentheses where applicable.

Product best practices

Interviewing for PM roles

Product Execution

Product Strategy

Frameworks

Data Analysis and tools

Software architecture

Design

Product vs. …

Processing…
Success! You're on the list.

Free product requirements document (PRD) template

Use or delete sections as needed! You can find the Google Doc version of this template here. There’s also a “lite” version here.

Problem statement

Here’s a one or two sentence overview of the project or feature. The level of detail should allow users to visualize what the following sections are about, but should not be too prescriptive about the actual design implementation.

Stakeholders

Clients or stakeholders required for sign-off:

  • First name, last name, role
  • There shouldn’t be too many people here, these should only be the folks needed for signoff
  • You can indicate where each stakeholder is on the RASCI chart (in parenthesis like this.) 

Collaborators who are in other departments, vendors, or agencies:

  • Another person in a supporting department
  • A point person at an agency 

Internal approvers from your own department who review work before it’s sent to stakeholders:

  • A creative department lead
  • The account point person

Personas

Who is going to be using this new feature, product, or service?

Goals

Toward what end will consumers make use of this? 

You should be able to summarize the high-level goal of this project in one sentence. Goals are lofty and hard to measure, like “become a leader in machine learning” or “provide support for working mothers.” This should inspire your team when the going gets tough.

Objectives & Key Results

Objectives are tangible and measurable. Project objectives should clearly map to higher-level business strategy, and should clearly state how the impact on those goals will be measured. This is a great place for your project KPIs. You can also include a baseline for each KPI, if known, and a timeframe expected for improvement. Once it’s created, you can link to your dashboard from here and maintain this PRD as on-boarding documentation for future users.

Example ObjectiveHow will we measure success?Current benchmarkTarget improvement
Improve productivity of the customer service team by reducing time to resolution for help tickets.time / resolutionAvg. call duration 6 minutes.
Data Source: Zendesk.
↓ 1 minute / call

Research

Here, you might want a quick introductory paragraph about your research methodologies. How many people will you interview? In-person or over the phone? How will you source these users? What open questions are you hoping to answer from this research?

User insights

Once your research is complete, it’s helpful to conversationally summarize insights in paragraph format, and include a link to your long-form qualitative or quantitative data. Your research might validate your assumptions, or you might have found something surprising. Be careful not to focus on interesting — but outlier — information. Make sure your takeaways accurately represent the overall feelings and behaviors of your test cohort.

Business (or product) requirements

Requirements are a combination of tactics and constraints — things you must do, and things you must not do.

  • A requirement might look like “users must only be able to enter one email address.” This is a functional requirement.
  • A requirement might also be a “soft requirement,” like “need to carefully manage scope and time because this needs to launch a few weeks before the summer conference.” These are business requirements.
  • Requirements should be written in plain English, and conversational enough for most people on the project to be able to understand at-a-glance.

Technical requirements

  • If you have more than a dozen of these, I recommend including a link here to long-form technical documentation.
  • Remember to include the scope of supported browsers and devices in your technical documentation.
  • If you only have a handful of requirements, they can be written like “End users should see an error if they attempt to sign up with an email address that is already associated with an account. The error needs to include a link to login and another link to the forgot password flow.”
  • If many teams will be referencing these requirements, it can help to number them, like this:
    • R001 — Requirements can be numbered
    • R002 — Numbering system should start with a few leading zeros for scale 

Accessibility requirements

  • Accessibility requirements are not just technical requirements, so it makes sense to put these in their own section as they often affect UX and Design as well as the tech department.

Resources

  • I’m a link to an API dependency
  • I’m a link to a style guide or design pattern library
  • I’m a link to the version of Python that the backend is written in
  • I’m a link to a similar campaign this client really liked and wants to model her project after 

Open questions

Note: In initial stakeholder interviews, I find that the maximum number of questions we are able to answer is 8, whether the interview is 30 minutes or 90 minutes. Trim your list to the most valuable 8 pieces of information you need to elicit and plan for follow up interviews. I also like to place this section last so that if the answers start to grow to a few pages, everyone can still easily skim the less frequently changing sections above.

Some example questions to start off the conversation:

  • What do you believe should be our main objective?
  • What pain points keep you or your users up at night?
  • How are our users currently working around this problem?
  • Do you have internal users who might also be using this tool?
  • What constraints do we expect to encounter?
  • Is there anyone else we should speak to about this?
  • What does success look like for this particular experience?
  • What does failure look like?

Processing…
Success! You're on the list.

Product Thinking

Divergent thinking is the art of generating abundant ideas, unbound by false constraints.

Convergent thinking is the skill of distilling many ideas into a focused few.

Diverging to create choices and converging to make choices is the basis of Design Thinking.

To invent solutions where there are none, and then identify the right way forward, product people must switch between divergent and convergent thinking regularly, flexing these perceptions like a muscle. Generate as many ideas as you can, refine. Generate, refine. Repeat.

I call this exercise “Product Thinking.”

It’s important to time box this cycle, to protect ideas and give them time to grow and evolve, and to prevent burrowing too far into a convergent hole before noticing changes in the market or user behavior. 

Some people have a natural talent for Product Thinking. Others are stronger in one area than the other, and struggle with context switching. Everyone must become skilled at Product Thinking to deliver useful products reliably.

Stay tuned for a 5-part post on convergent processes for generating a solid product roadmap.


Processing…
Success! You're on the list.

Innovation ≠ invention

Co-authored with my husband, Ben Horowitz.

Before you start building any new solutions, it’s important to understand the difference between innovation and invention.

This is an important distinction because invention is more expensive than innovation. I use the word expensive, not about money but about all resources. It takes more time, money, effort, and opportunity cost to invent a solution than to find an innovative one.

Innovation is simple

Innovation is very straightforward. You take a solution that you know works in one place, and you apply it to a similar problem in a different space. Break down the problem you’re solving into its most simplistic form. What is the core of the problem? Then, look to other industries and disciplines to see if there were similar problems that have already been solved. You may be able to introduce an old solution in a new way. That’s innovation.

Invention is complex

Invention is a different mechanic for problem solving. Invention is where you start for problems that are totally unsolved. If you have no idea what might work, you start structuring experiments to chip away at the unknown. When you find a few things that work a little bit, you can expand on that knowledge until you find a solution (maybe, but not always.) Invention is a last resort when no other known solution will work.

If “chipping away at the unknown” is how you’d describe your backlog, then you might be inventing a solution. Try looking for an innovative solution first. What you find might not work perfectly, but it may significantly reduce the scope of the unknown. Then fewer experiments and feedback loops are needed to succeed.

Pattern matching on the problem

There’s an excellent example of the cost-saving benefits of innovation in this HRB article:

“One of the best innovation stories I’ve ever heard came to me from a senior executive at a leading tech firm. Apparently, his company had won a million-dollar contract to design a sensor that could detect pollutants at very small concentrations underwater. It was an unusually complex problem, so the firm set up a team of crack microchip designers, and they started putting their heads together.

About 45 minutes into their first working session, the marine biologist assigned to their team walked in with a bag of clams and set them on the table. Seeing the confused looks of the chip designers, he explained that clams can detect pollutants at just a few parts per million, and when that happens, they open their shells.

As it turned out, they didn’t really need a fancy chip to detect pollutants — just a simple one that could alert the system to clams opening their shells. “They saved $999,000 and ate the clams for dinner,” the executive told me.” 

http://bit.ly/2S3rOEK

That’s innovation.

Stanford bioengineers develop a hand-powered centrifuge, dubbed the “Paperfuge.” How might you achieve the functionality of an expensive medical machine in places with no infrastructure? Well, break the problem down to its simplest form: what’s cheap, doesn’t need power, and spins really, really fast?

“It is an ultra low cost centrifuge that’s built out of principles of a very old toy, the whirligig.

… We were able to essentially make a centrifuge that spins all the way to 120,000 RPM and 30,000 g forces. In the lab, we can separate and pull out malaria parasites from blood, we can separate filaria, African sleeping sickness, separate blood plasma.

… We can match centrifuges that cost all the way from a thousand to $5,000, but this is a tool that requires no electricity, no infrastructure. You can carry them around in your pockets for a price point of 20 cents.”

http://bit.ly/3b12ZSA

That’s innovation.

My favorite TED Talk was given by Tal Golesworthy, an engineer with a heart condition who realized that weak arteries at risk of bursting look a whole lot like a standard plumbing problem. He outlines some of the unique challenges his cross-functional team encountered while designing an implant that externally braces the aorta, preventing rupture and negating the need for open heart surgery.

That’s innovation.

These stories are of cool, interesting, and successful ideas. But that’s not what makes them innovative. We already knew these solutions solved problems — detecting pollution in water, bracing leaky pipes, creating centrifugal force with only manual power. We understood the mechanism by which they solved these problems. The innovation was recognizing that a similar problem existed in a different space that might also be solved by these existing solutions.

Multidisciplinary teams and diversity 

These examples have something else in common. Each of the teams responsible for these innovations was made up of people from diverse backgrounds. Someone with seemingly unrelated knowledge happened to pattern match the problem they were facing here with a problem they had seen before in a different domain, to arrive at solutions beyond the body of knowledge associated with that domain.

  • The marine biologist solved the pollution sensor problem in a way that the chip designers would never have known about.
  • Tal Golesworthy applied his knowledge of plumbing to his circulatory system in a way doctors didn’t know could work.
  • The Paperfuge problem was solved when one of the team members remembered a childhood toy from India that spun really fast, and decided to analyze how it worked.

And, the similarities were immediately evident to the people who had seen these problems before. It may still have taken a while to finesse the solution to fit the new problem space, but that initial spark of innovation happened right away. Humans are very good at pattern matching — often too good, in fact. Pattern matching on the problem is where innovation begins. More diversity on your team means more opportunities for these happy coincidences to ignite innovative ideas.

If you’re trying to fix an innovation problem, start by fixing a diversity problem. Do you have a wide breadth of knowledge, education, and experience on your team? Homogeny inhibits innovation.

The high costs of failing to innovate

I once failed to turn an EEG device into a music input into an instrument by mapping it to MIDI sounds. EEG files were gigantic at the time, and being in my early 20s, and couldn’t afford enough hard drives for the project. So I was researching EEG file compression. I came across a paper written by PhD students from the University of Malta, who had spent their entire semester and grant trying to apply a JPEG compression algorithm to EEG files. My husband, the audiophile and engineer, was dumbfounded. EEG is wave data. We have existing — efficient! lossless! — compression algorithms for wave data: any kind of audio compression. Inventing a way to compress wave data with a lossy image algorithm struck him as absurd.

That’s why it’s important to investigate your innovation options before you start inventing. In this case, inventing a solution was wholly unnecessary, and in fact, the result has caused diagnostic issues. The lossy compression format can omit “diagnostically relevant” data for patients with epilepsy. With a more diverse team, this could have been avoided. A computer scientist or an audio engineer would have helped the neuroscientists select the right algorithm for the problem of compressing wave data.

Use innovative hypotheses to shorten your experimentation process

I am a huge proponent of experimentation and feedback loops — trying things, learning things, and feeding that knowledge back into the experimentation process. But it may not always be necessary to start from square one. Put together a diverse team. See if you can start with an informed hypothesis from solutions in other spaces. Do your research and amplify other’s efforts. That’s innovation.


Processing…
Success! You're on the list.

Influencing without authority

Product Managers sell futures in never-before-seen, intangible things. To earn buy-in, you need to help people visualize what this is and get excited about it. If you’re asking people to give you resources to build it, they need to feel the painful void of not having this yet and to itch for it to exist.

This takes a little sales and swagger. You need buy-in from your boss, their boss, and key stakeholders. You also need support from influencers inside your company — people that everyone else listens to.

If you find yourself struggling to reach alignment, start by reading How to Win Friends and Influence People by Dale Carnegie. There is only one thing I’d argue against in that book. You have to get someone to want the same outcome that you want, not just to want to do the same thing. If they are attached to a method rather than an outcome, you lose your support from this person if (and inevitably when) you have to pivot directions. Getting buy-in on a vision means you have an advocate until you’ve seen that vision come to life.

The term “Influencing without authority” amuses me. It assumes that if one had authority, it would be easier to influence. I’ve found the opposite to be true; people are often reflexively resistant to authority. It’s quite a bit easier to learn what people are really thinking when you don’t have any authority over them. This makes it straightforward to introduce new ideas and information to get them more aligned with the way you see things.

But whether you do or do not outrank them, you will always encounter people who are resistant to the changes required to bring your ideas to life. Perhaps they feel overwhelmed by the potential changes to organizational structure, to workload, to the effort required to earn their paycheck. Maybe they are resentful that you’re messing with “the way things are done around here.” Or perhaps, they are incredibly driven, hard-working people for whom your proposal just doesn’t line up with their understanding of the future — what motivates them, what vision they are working toward, which truths they believe. This last group of people is hardest to inspire toward your vision because they are already inspired toward another.

It won’t matter how right you are. For people who resist the change you propose, there is something in this person’s life that weighs heavier on them than you can push against. It’s a waste of your limited resources to keep pushing. The only way to overcome this kind of inertia is to spark within this person a desire for the same outcome that you have, for the same vision.

Look at the forces and ideas pulling those people toward their focus, instead of trying to find forces pushing them away from your ideas. You’ll have to zoom out a little to see this. If you can see the ideas that this person gravitates toward, it’s possible to find an even more fundamental truth that encompasses both of your viewpoints. That truth may help align people toward a new goal, together.

You don’t influence teams, you influence people. You steer teams by making small adjustments to the way you interact with the people on it. And to do this, you must first understand what each person worries about and wishes for.

This requires a considerable amount of empathy and a large investment of time. This also requires a willingness to be vulnerable. You must share your own motivations and fears, to build trust with this person so that they, in turn, open up to you. See if you can draw a connection between your vision and their personal success. There’s almost always mutual benefit in doing good, impactful work. It should go without saying that this nudge should always be genuine and have this person’s best interest at heart. People will see right through self-serving agendas.

Try articulating your vision a few different ways to different people. See what clicks consistently to nail your pitch. Have patience, too. It may take commitment to a vision over a longer-term for people to begin to really think about whether there’s something there to jump on board for.

Recommended:


Processing…
Success! You're on the list.

Product First Principles

My uncle Ronnie, whom I think I met only once when I was 3 years old, taught my father how to drive according to his 4 rules of driving. My father, in turn, taught me and I’ve never forgotten them. In no particular order, they are:

  • Anything bigger than you has the right of way,
  • Never back up an inch further than you have to,
  • Never drive faster than your headlights,
  • Always be wondering what the stupidest thing the cars around you could possibly do, and then be prepared for them to do that.

When I was 15 and learning to drive, this list terrified me. Years later it amused me. But now, this list fascinates me — in two decades, I have yet to find anything I’d add to this list before I teach it to my son. Everything on this list has saved my life. Adding more information might distract from these memorable truths of “how to not die in a car accident.”

The clarity, honesty, and brevity of this list frame my understanding of first principles, which I seek to identify in everything I learn. What are the elemental, atomic truths that hold true in all cases? These are the things worth knowing, worth writing about and passing on to others.

In my ten years of product experience, I’ve sought out scholarly articles, books, and modern-day philosophers of product first principles. And I haven’t found many. It seems this way of looking at the world may be too new to have come fully into focus. There are no university degree programs, no classical education tracks for the fledgling product person. But surely there are first principles worth writing about.

That’s the basis for this blog. I haven’t got it all figured out, but I hope that as I write, others may find this exercise interesting and join in on my hunt for product first principles. I’ve identified a list of topics worth writing about, in no particular order:

  • Influencing without authority
  • Frameworks vs. feedback loops
  • Design to learn
  • Anecdotes are not data
  • Innovation ≠ invention
  • Divergent & convergent thinking
  • Simplifying complexity
  • Desire paths
  • Outcomes over output
  • Iteration is subtractive, not additive
  • Efficiency of teams, not people
  • Minimum viable
  • Single points of failure
  • Systems of record
  • Required vs. desired
  • Scope & specificity
  • When to endure, when to fail fast
  • Bias & cognitive chunking
  • Inputs & outputs
  • Reject cognitive load
  • Validate unknowns

If this list looks like stuff you’d want to read about, follow along!

Processing…
Success! You're on the list.