5 steps to building our Product Roadmap

A note for new subscribers: This post is part of a monthly series on my notes on technology product management (this is what I do for a living). You might notice that these posts often link to older posts in the series on LinkedIn even though they are all available on this blog. That is intended for folks who only want to follow future product management related posts. Finally, for all those of you who don’t build tech products for a living, I believe many of these notes have broader applicability. And, I hope you find that to be the case as well…

A quick overview of what we’ve covered on “Notes on Product Management” so far –


In our last post on Notes on Product Management, we covered how we’ll build our strategy. Thanks to the experience of going through the strategy creation process, you and the product team understand where you need to focus. The next step is to translate that into a product roadmap.

A product roadmap is a high level summary of what we will build to execute on our strategy. I’ve laid out the 5 steps that I’ve found helpful below.

Unlike prior posts, this post will very tactical and, thus, long. I’m going to do my best to share rationale – but, in many cases, there’s a lot of learning from various iterations (read: stumbles and missteps) baked into these notes. So, please feel free to ask questions in the comments and I hope you find it helpful.

Step 1 – The Roadmap brainstorm: The first step to building the team’s roadmap is a brainstorm with the entire product team.

The best scenario is when every person on the product team is present in-person. Co-location is very powerful. Even in the case of a largely remote product team, it is worth waiting to have everyone together as part of a team event to do one of these. A good brainstorm session can take anywhere between 2 hours to 4 hours. These can be shorter – but it is generally worth the time. (If you’re wondering about the remote version of this given the circumstances, don’t worry – I’ve got you covered below)

For details on this step, I’m going to get very tactical (forgive me):

i) Invite everyone on the team – below is a snapshot of the folks who may be on your invite list

No alt text provided for this image

ii) Book an airy room with a view – It is worth booking the best room in your building well in advance. You may even want to consider taking the team offsite to do this (you will just need a white board).

iii) Agenda –

a) Objective: This meeting will be successful if…. a) we get to know each other, b) align on context – strategy, data, and user feedback, and c) brainstorm product ideas to execute on our strategy. I also share that my success metric for this meeting is “% of shut laptops.”

b) Fun intros: Invest in doing something beyond having folks introduce themselves. Fun facts, 2 truths and a lie, interesting questions, cross introductions, etc., are ways to make this fun. Time invested in getting to know each other is always well invested.

c) Context:

i. Strategy: Remind everyone of the strategy.

ii. User research/feedback: Request the “Voice of user” team to share a 1 slide synthesis of user research/feedback

iii. Data: Similarly, request the “Voice of data” team to share a 1 slide synthesis of data

d) Brainstorm:

i. Prompt: Share the prompt – What are 3 features you would prioritize for us to successfully execute on our strategy?

ii. Brain-writing: Give everyone 5 minutes to write their individual ideas down on post its – this will ensure every member of your team (especially the quiet ones) have time to think

iii. (optional) Group brainstorming: Split folks into teams of 3 or 4 and ask them to discuss for another 5 minutes and further hone their ideas

iv. Summarize ideas: Go to a whiteboard and ask every person to share their ideas with their reasoning – as they share their ideas, cluster similar ideas in groups as themes will inevitably emerge

v. Prioritized vote: Next, and most important, ask every member to vote for their top 2 across all ideas and tally the top themes. Inevitably, 3-4 high priority areas will emerge.

It is impossible to over state the importance of the prioritized vote. It is the step that separates a successful brainstorm from a failed one. Failed brainstorms have organizers take back sheets or photographs of un-prioritized ideas. In successful brainstorms, the entire team walks out with a shared understanding of the few things that matter.

e) Next steps: Promise to synthesize the results of the brainstorm in a roadmap sheet that you will share with the team.

An outcome I’ve observed over the years – a team with shared context always converges on the right set of big ticket items that matter. This is the most magical part of well run brainstorms. You don’t need to pre-alignment meetings to get alignment within your team. Setting context will do.

And, if you are remote, there’s a way to do this remotely too. You just need to set up a spreadsheet where everyone can vote. Below is a screenshot and click here for a sample spreadsheet.

No alt text provided for this image

Step 2 – Organize your plan to ensure you are taking a portfolio view: The next step is to go through your plan and organize your bet into a portfolio view. The 4 buckets I’ve found helpful to use are –

    1. Foundational: These are bets to strengthen technology foundations, remove tech debt, improve experimentation, and developer productivity. Some of these bets can have surprisingly large impacts on metrics that matter because they improve sitespeed/latency and remove other performance issues.
    2. Core: Items in the Core bucket directly and immediately impact the metrics that matter.
    3. Strategic: Strategic bets are those that work toward a mid-longer term plan – they will likely not have immediate metrics impact but are either likely to pay off in the mid-term or make it possible for other high-value “core” bets to work. Features that improve user delight or improve NPS often fall into this category.
    4. Venture: Much lower probability of this working out – but, possibility of large reward if it does.

3 common questions that come up when discussing these buckets.

i) Is there a correct allocation between the buckets?: No. This is entirely situation dependent. If you are going through a massive technical migration, you will have a large allocation on “Foundations.” If you are under urgent revenue pressure, your “Core” bucket may be heavily stacked. So, use your judgment.

No alt text provided for this image

If there is a mistake to avoid, it is over-indexing on “Core” to optimize for short term metric wins. I’ve personally found a ~20%-40%-40% balance between Foundational, Strategic, and Core to be optimal as it ensures we’re making progress across the board. I don’t generally make allocations for venture bets because those allocations are best made at the level of a business unit vs. in an IC PMs portfolio.

2. Where do you allocate time for fixing bugs?: There are two kinds of bugs – blockers/criticals and everything else. All blocker and critical bugs need to be triaged, by definition, immediately.

Other bugs that fall into “everything else” bucket require judgment. Often times, non-critical bugs point to workflows that need to be re-engineered – these can be incorporated in the “strategic” bucket. The rest is up to you. Different folks have different philosophies on it and these also need to vary between enterprise products and consumer products. I don’t know if there is a right one – the only thing that matters is picking the philosophy that works for you, your team, and your product.

3. What is the best tool to use to create this roadmap?: I don’t know. Maybe there is one – then again, there may not be. I’ve found spreadsheets to be wonderful personally. But, I also tend to be a minimalist when it comes to tools. So, feel free to experiment… just remember again that there is no right answer. Find one that works for you and your team.

Step 3 – Figure out if you can accelerate progress via partnership or M&A: Building a product internally is just one way to achieve your goals with a positive RoI. You can also accelerate your progress via two other strategic options – partnerships and, every once in a rare while, M&A.

No alt text provided for this image

If you believe there is an M&A target or two worth considering, build a strong working relationship with your investment/Corp Dev team to build out the investment case. In such cases, make sure your investment/Corp Dev team members have full visibility of your strategy and roadmap (invite them to that brainstorm!).

M&A aside, more often than not, you will likely find ways to partner. There are again two ways to do this –

    1. External partnerships: Most mature companies have a Business Development team that can add a ton of value here and can even be central to your strategy depending on the product. In one of the products I worked on previously, our Biz Dev lead was a core member of our R&D team and a key voice in every product decision. Many a time, these external partnerships also end up being the pipeline for potential M&A.
    2. Internal partnerships: This is often overlooked – particularly at large companies where this can be incredibly valuable. Ever so often, there are internal teams who can help you significantly accelerate your progress toward your goal. They may have already built the tech you are seeking to leverage or may be able to enable you to broaden your impact. Such partnerships are a massive internal win because it ensures teams aren’t doing duplicative work while also ensuring your users get one consistent experience across the product. And, if you do your part in investing heavily with relationship building, generous sharing of wins and credit, these partnerships can be massive bright spots – both professionally and personally.

Step 4 – Share a high level visual in your strategy doc: Bring this back to your strategy doc with a high level visual that breaks your roadmap either in quarters or 6-months/halves. Enterprise roadmaps can go as long as two or three years. But, if it is a consumer roadmap, 18 months is about as long as it probably makes sense (it is unlikely you’ll go 6 months before changing it again :-)).

Use this visual to check if everyone is bought in and if the timelines makes sense – this is especially important if you are running an enterprise product with go-to-market commitments. Below is an illustrative visual – it tends to be helpful to bring cluster features within initiatives that seek to help us execute on our strategy and drive toward metrics that matter. These strategy pillars and metrics, in turn, hopefully map straight to the user/customer problems we set out seeking to solve.

No alt text provided for this image

5) Set expectations both externally and internally: Once the team is aligned, the final step is to set expectations.

a) External: Your GTM partners will now use the roadmap to create the customer/user education plan. This may involve previews, presentations, updates to client decks, and the like.

b) Internal: The more tricky part is setting internal executive expectations. This is especially important if you are planning strategic bets or key infrastructure upgrades that may impact your metric forecasts. This is the biggest area where I’ve seen folks make mistakes – and it is definitely the area where I have some painful war stories myself.

The key here is to take the time to work through the first and second order effects of your planned roadmap. Ask yourself – what will be the impact to metrics that matter for each initiative? Then, think through what happens when all the initiatives roll out together – will there be any compound effects? Finally, think about initiatives partner teams are planning to undertake – do any of them impact your strategy?

When you go through that exercise, you will likely realize that there are a few curve balls that you need to further flesh out. If you are managing a business with revenue expectations, work through these steps diligently with your Finance and Ops partners so you know what to expect. Once you know what to expect, communicate and get exec support.

The better your own understanding of what lies ahead and the better you set expectations, the more freedom you’ll have to execute on your vision. Fail to do that and your roadmap will just be a spreadsheet full of ideas that never saw the light.


Building good roadmaps is a core aspect of an IC PM’s job. But, how these roadmaps get built is often misunderstood. It is the PM’s job to facilitate the conversion within the product team and use the team’s collective brainpower, insight, and perspective to create this roadmap. As a result, we can’t just walk into a new team and build a roadmap. Those kinds of roadmaps result in poor products.

Instead, we need to take the time to get to an understanding of the core problems, articulate them in clear problem statements, define a strategy with the team, and then build the roadmap. When we walk into a new team, we often have to do this in parallel with executing on an existing roadmap.

The outcome of a well run process is a team that is aligned and rowing in the same direction. And, a test of this is when they refer to the roadmap as “our roadmap” instead of “the PM’s roadmap” or “your roadmap.”

When that begins to happen (and it often takes time and a lot of reinforcement), good products and happy users/customers generally follow.

What is strategy and how do I build product strategy?

A note for new subscribers: This post is part of a monthly series on my notes on technology product management (this is what I do for a living). You might notice that these posts often link to older posts in the series on LinkedIn even though they are all available on this blog. That is intended for folks who only want to follow future product management related posts. Finally, for all those of you who don’t build tech products for a living, I believe many of these notes have broader applicability. And, I hope you find that to be the case as well…

A quick overview of what we’ve covered on “Notes on Product Management” so far –


What is strategy?

The best definition for strategy that I’ve come across is that good strategy answers 2 questions –

    1. Where should we play?
    2. How will we win?

The “where should we play” question defines our target customer/segment/market and the “how will we win” question tackles how we will differentiate ourselves from our competition.

A clear and well articulated strategy makes it possible to do fewer things better by helping everyone on the team separate signal from noise and easily articulate the trade-offs involved. So, if you’re hearing about or feeling a lack of focus or alignment within your product team, it is likely because of the lack of a coherent strategy.

That said, a well articulated strategy is still just the first step. A well executed strategy is the next step. When a strategy is well executed, it becomes easy for the team to reflect that understanding in their prioritization – i.e. the team can go from understanding the trade-offs to living those trade-offs. A well executed strategy requires the leadership team to align incentives (success metrics, pay, recognition) in a way that makes it easy for folks on the team to make the strategy come alive.

A simple test of this is to ask members of the team a) what they are focusing on and b) what they are not focusing on and why. If you have coherent answers on both, you are witnessing an exceptional example of executing on a strategy.

An example

When Bob Iger took over the CEO of Disney, his strategic vision focused on 3 pillars –

1. Generate the best creative content possible

2. Foster innovation and utilizing the latest technology

3. Expand into new markets around the world

If your first observation is that this isn’t rocket science, you wouldn’t be wrong. That may just be the first takeaway as you’re thinking about strategy – it is easy to articulate a simple strategy. And, it also turns that good strategy is often simple.

Disney, at the time, had a flailing animation division and had fallen behind Pixar (with whom they had a failing partnership) in generating great creative content. They also didn’t have any technological edge to speak of. As a result, the acquisition of Pixar became a relative no brainer – in hindsight at least. Iger and team continued to acquire multiple creative studios with incredible IP – Marvel and Lucasfilm are great examples of this – to continue doubling down on the “best creative content” pillar.

Fast forward to the launch of Disney+ last year and you can see how this strategy came together. Disney+ was made possible by acquisitions above that gave Disney the library of creative content to become a formidable global streaming player right from the get go.

And, the Disney+ launch is also important because it offers a telling story about the difference between a clear strategy and a well executed one. In the year leading up to the creation of Disney+, Bob Iger needed every one of his executives to support this new bet. However, and this is the predicament most leaders of complex businesses face, it is impossible to change behavior when they’re already compensated on how well they manage their existing (successful) businesses.

So, Iger requested approval from the board to move all his executives’ performance based compensation from metrics based on the success of their existing businesses to an evaluation by him on how well they were supporting the Disney+ launch.

That was a master stroke and a demonstration of the art of incentive management by the Obi-Wan Kenobi of CEOs.

So, how does all this apply to me as an Individual Contributor PM?

Your product team could do with a strategy. If you have a clearly defined strategy defined for your organization by your product leader that you are already executing toward, that’s great.

But, if you don’t or if that strategy isn’t yet directly translatable to your team, read on.

Let’s start with the obvious – ideally, every organization has a clear strategy. That strategy, in turn, would enable every product team unit to focus on doing things that ultimately move the needle and win.

But, it doesn’t always work out that way. That isn’t always down to leadership incompetence (though, sometimes, it is). The more complex and large the business, the harder it is for leaders to make statements about focus without risking de-motivation of the areas of the business that aren’t the focus areas at the moment.

So, if you are faced with situations where you are unclear about the strategy, there are 2 things you can do – 1) Ask the leaders (this is the obvious first step) and/or 2) Look at the metrics that matter.

The metrics used to measure success are the simplest manifestation of the strategy. Even when a strategy isn’t articulated clearly, understanding which metrics are emphasized over others helps understand what matters to leadership.

Assuming you have clarity on the organization’s strategy, it is now time to write your own strategy doc.

So, how do I write that strategy doc?

Here is a structure I’ve found useful.

I. Outcomes:

User/Customer Problem: Attempt to synthesize the top user problem you are seeking to solve. And, if you are representing a multi-sided marketplace, lay out the top problem for both sides of the marketplace. Stick to one overarching problem to avoid a laundry list – the purpose of this exercise is to bring focus.

Outcomes you are seeking to drive: Lay out the top 2 “true north” metrics you choose to drive along with a guardrail metric or two. 2 things to keep in mind when choosing these metrics –

1. The true north metrics would ideally be the metrics that matter to your organization. If you have no way of moving those metrics, add “Signposts” that you can move and that you believe will eventually move the true north.

2. Be thoughtful about guardrails/negative metrics and companion metrics. A negative metric if your strategy involves sending customers more email would be unsubscribe rate. Once you’ve got negative metrics sorted, take care to ensure you have companion metrics. Great metrics often work in pairs – e.g. depth and breadth metrics (Weekly active users and time spent per login), revenue and RoI.

If the outcome section reminds you of the problem statement, that’s exactly what it is. Product managers are problem managers.

II. Strategy: Let’s go back to the two questions we laid out when we started – “where do we play?” and “how will we win?” Outside of cases when IC PMs are hired to work on a venture bet, the answer to the “where do we play” question should generally be part of the organization’s strategy. This answer defines the audience whose problems you solve as part of your roadmap.

Our focus, then, is figuring out how to win. And, we do that by taking a stand on where we will focus our team’s energy. It is helpful to articulate these focuses in the form of 1-3 themes or pillars that all contribute to the desired end outcome. These themes work well when they connect to a journey – e.g. acquire -> retain -> monetize – or similar. They can also work well when they clearly ladder up to solve the top user problems you’ve set out to solve.

When done well, the strategy helps everyone understand exactly what we are doing and not doing. So, if you find yourself attempting to organize a catch all list of everything without needing to make hard, sometimes painful, trade-offs, that is not a strategy. That is just a list.

A great way to bring this section to life is to illustrate the user/customer experience 12 or 18 months later after successfully executing on your strategy. Doing so can help folks on the team clearly visualize what success looks like.

An important note – a collection of product principles is not a strategy: It is easy to confuse a strategy with a collection of product principles. Your strategy helps you create a focused plan to ensure you are the go-to solution for the problems of the audience you choose to serve. Product principles, on the other hand, are the values of a product. Product principles are best agreed upon at the level of the entire organization and are analogous to the values of a company. You rarely change them and they represent the choices you make without considering the trade-offs involved. You commit to them because you believe they are the right thing to do.

III. Roadmap: The next step is to lay out what this means in terms of feature ideas. The goal here isn’t to have product specs ready – not yet at least. Instead, the goal should be to get a low definition set of ideas that both feel right and have the team excited. (We’ll aim to cover roadmaps in detail in the next post)

Write all this out in a 1 page document. If you’re not able to synthesize your strategy in a page (with 0.5 inch margins :-)), then you don’t have a clear strategy.

The final test of a clear strategy is that it will make it easy for every member of the team to differentiate between ideas that matter and ideas that don’t. And, if that’s happening, we’re through with the first step.

How, then, do we move to the more important step – moving from well articulated strategy to well executed strategy if we don’t control the incentives of the product team?

By winning the team’s hearts and minds.

This, in turn, happens when we involve folks on our team early and often. Get started with the door wide open (i.e. ask everyone for opinions and ideas), then write your first draft with the door closed, and edit and revise with the door wide open again.

The more the team is (and feels) involved, the more likely it is to be successful.

Therein lies the magic of the strategy creation process. When it is done well, it helps get the entire team aligned and rowing in the same direction. That in turn magically resolves disagreements that might otherwise have showed up in future product specs and prioritization discussions.

If we’re then able to celebrate instances when team members execute in ways that support the strategy, we make it all the more likely that the strategic process we followed has ensured these ideas have now moved from theory to practice.

Do this often enough and the odds are good that we’ll end up building a track record that includes a run of valuable and successful products.


A career and life sidebar: The test of a good strategy within the product team applies just as well to our life and career. If we’re able to consistently articulate what we focused on alongside what we are not focused on, we’re making great progress toward being effective.

And, if we’ve picked focus areas consistent to who we are and who we want to be while being comfortable with the trade-offs we are making as a result of those choices, we’re on the path toward the only kind of success that can leave us feeling fulfilled – the kind that we intentionally chose for ourselves.

Gunpei Yokoi and the Lefty Rx

Gunpei Yokoi, then a creative game designer working at Nintendo in the 70s (before he became a legend), wasn’t the sort of person who was at the forefront of technology. So, he focused on creating games with an approach he termed – “lateral thinking with withered technology.”

Since he couldn’t count on himself being cutting edge, he’d simply look to put commonplace technology in ways that made games more affordable for Nintendo customers. One such technology he was interested in was remote controlled cars – then an expensive luxury in Japan.

Since these cars were expensive due to all the functionality required to control the car, he decided to simplify things by launching a car with just one button that could only turn left – the aptly named Nintendo Lefty Rx.

Its price made it easily available to a massive customer base who enjoyed racing these cars across circular tracks. Even when there were obstacles, you could left turn your way out of it – only adding to the excitement.

I love stories that demonstrate the power of simple, functional products that get the job done. The Lefty Rx is a great example of how simple can be very powerful.

The 80% experience

A question that has helped point to better product design every time I remember to ask it – what is the experience 80% of the users would want to go through? 

When asked, that question first reminds us that we must let go of all the complexity we are likely to introduce as super-users of our own products.

It then pushes us to simplify our flows to the few things most users care by removing any detailed how-to notes, unnecessary choices/steps, and excessive copy.

And, out of this exercise emerges a principle that applies just as well to product or process design as it does to effective communication – focus on clarity over completeness.

Your manager in the product team

A note for new subscribers: This post is part of a series on my notes on technology product management (this is what I do for a living). You might notice that these posts often link to older posts in the series on LinkedIn even though they are all available on this blog. That is intended for folks who only want to follow future product management related posts. Finally, for all those of you who don’t build tech products for a living, I believe many of these notes have broader applicability. And, I hope you find that to be the case as well…

Let’s imagine we posed a question to a group of Product Managers – can you share the list of folks/functions on your product team?

What list would you expect?

When I’ve asked this question, I’ve received answers that I cluster into 4 groups (illustrative).

This turns out to be a helpful way to think about the product team as well… with one exception.

That exception is one that is often absent from lists that describe the product team – the PM Manager

I consider that a big miss because good PM managers play two vital roles to help IC/individual contributor PMs be effective-

A) They help provide the organizational context and feedback you need to be successful: This includes providing clear guidance on overall strategic direction that helps you align your strategy/metrics and also providing feedback on your plans based on their experience.

B) They provide air cover when you need it (and it is likely you’ll need it this week): This is the more critical role the IC PM manager plays. In cultures that hold PMs as the “DRI” or Directly Responsible Individual, the IC PM is accountable for the performance of the product without having any formal reporting authority over the product team. As a result, executing parts of the job may involve pushing folks/rubbing folks the wrong way (when the pushing is over done as you figure out the right balance) from time to time. In such times, air cover is key.

Air cover isn’t just about your manager being the voice of reason to balance your role on the team. It also helps provide the space to execute with confidence that you have the space to try things and fail. An absence of air cover almost always results in an absence in experimentation and, thus, growth – both of the product and the person.

Finally, there is no one else in the organization who is more vested in your success. So, it is a bit of a no brainer to invest in this relationship. And, I’d go as far as to say highly functional product teams rarely become that way without a strong PM <> PM Manager relationship.

Building a great relationships with your manager: As in many matrixed organizations, the PM manager <> IC PM relationship can be a weird one. Depending on the nature of your product, you may be able to get by with little to no working overlap.

And, while there are a lot of folks who attempt to get by with that low touch relationship, my recommended approach would the opposite. So, here goes:

1. Invest heavily in getting to know and understand each other upfront. In a new role, spend time in your onboarding period to get to know and understand your manager. A simple way to do this is to request an hour to do a “user manual” session. Introduce yourselves to each other, share what matters to you and ask questions to better understand what drives them, understand how best to communicate with them, and what they’d love to see in a direct report.

The more you can get to know and understand each other upfront, the quicker you’ll enable trust to follow.

2. Share and involve them as much as possible – allow them to choose how much they’d like to be involved: With their permission, share and involve them as much as possible. Share early thinking/riffs on product direction/wireframes and invite them to brainstorming meetings/team meetings. If they show up on those docs and meetings, ask for feedback and act on that feedback.

I recognize this is sometimes viewed as contrarian advice. I’ve met with a few folk over the past months who’ve all shared situations that share a common cause – the absence of an open channel of communication with their manager. And, in every one of these cases, they were told by someone to only present “the good stuff” to their manager. So, they went through great pains to curate the good stuff and left aside topics that mattered – the pressure they were feeling, the challenges they were facing, and so on.

However, when they’re in the loop, they get to understand the challenges you are facing and how you operate. The better they understand this, the more they can provide specific guidance and trust you. And, the more they can trust you, the more context, scope, and air cover they will provide for you to steepen your learning curve and be successful.

There’s also limited long term upside in an out-of-the-loop manager. If you’re making big mistakes in doing your job, it is best you course correct at the earliest with help from the person who is most invested in making you successful. And, if you are doing your job well, that’s a really good thing for your manager to see.

And, if you don’t trust that your manager is invested in making you successful, it is likely time to leave.

Bonus tip: In the absence of your manager being able to participate in your meetings, a weekly 1:1 is a great forum to keep your manager in the loop. Keep a shared 1:1 doc, populate with the agenda in advance, and keep the hairiest topics right on top of that agenda.

3. For your part, do everything you can do make their life easier. Baseball executive Theo Epstein once said – “Whoever your boss is, or your bosses are, they have 20 percent of their job that they just don’t like. So if you can ask them or figure out what that 20 percent is, and figure out a way to do it for them, you’ll make them really happy, improve their quality of life and their work experience.”

There are many variants of this advice and they’re all valid. The principles at play here are as follows –

1. Everyone has a manager whose job it is to keep them accountable. Even the CEO reports to a board who, in turn, is accountable to shareholders. Understanding how to manage these managers is important for career success and happiness.

2. Become an incredibly valuable direct report and be the sort of person who removes more problems than you create.

These principles are, of course, equally applicable to the IC PM.

Managers make or break our experience. Aside from a few extraneous situations, it is highly unlikely we get anywhere if we have a poor relationship with our manager. In these situations, it is best to leave and find a new home.

On the other hand, if you’re considering a new role, it is worth prioritizing a connection with your prospective manager as among the most important criteria. When you choose well, you work with managers who appreciate your strengths and help ensure your weaknesses don’t get in the way.

And, every once a while, thanks to the power of incredibly aligned  incentives, these relationships transcend work relationships to become deep friendships.

When that happens, it turns out to be special – both for our career growth and our happiness.

Understanding the news and working with data

There’s a learning curve involved with understanding how the news works.

We might begin – as kids at least – with the assumption that the news is the objective list of everything of note that is happening around us/the world. But, we learn over time that a big part of understanding the news is looking beyond what is presented to us and asking 3 questions –

1. How was the information sourced/collected?
2. What have they omitted/chosen to omit?
3. What is the bias in their reporting?

Interestingly, the learning curve around working with data when we make product and business decisions is no different. The early promise of big data was that large amounts of data would solve any problem.

That promise didn’t pan out.

So, asking the above questions when we look at data/analysis and marrying a desire for data with a healthy skepticism for what it is telling us ensures we keep asking the questions that help get us closer to the truth.

As in the case of the news, better to replace “data driven” with “data informed.”