3 Tips for Managing a B2B2C Product

At HelloWallet, we sold web and mobile apps that helped employees improve their financial wellness.  The product was offered as a benefit to employees by their employer, who was our our client.  The B2B2C model is complex to manage – here are some tips I learned along the way:

#1 – Get KPI Alignment First

Make sure you know what outcomes your buyer is expecting your product to deliver, and how they’ll be measured.  Then, make sure you know what outcomes your consumer users are expecting, and how they’ll be measured. If the buyer and consumer outcomes aren’t aligned, stop. Do not pass Go. Figure out how to get them aligned before proceeding. After all, your buyer is paying for consumer behavior change, and if your product doesn’t help consumers with an urgent problem they want help with, your product won’t last long.

At HelloWallet, our clients were looking for a variety of things –  productivity gains due to less financial stress, “engaged” employees, retirement readiness, and retention.  As you might imagine, the solution could take many different forms based on which of those outcomes was most critical.  It’s important to make sure you know exactly what metric the customer will use to measure success.  During sales calls, I would often ask:

How will you measure the success of this program in a year?  How will you know if HelloWallet is “working”?

Sometimes they didn’t have an answer, or they focused on metrics like adoption and engagement that I knew weren’t enough to justify our fees come renewal time.  Make sure you have a definitive answer to this question from prospective customers.  Work with your sales, account management or user research colleagues to solicit the answer to this question.  Also, don’t pick more than 2-3 Key Performance Indicators – otherwise they’re not “key.”

(Note: the KPI(s) you select with clients should be consistent across clients.  If you’ve already established KPI(s) with existing clients, new clients should hear that is how you measure success during the sales cycle. Otherwise you’ll end up with an unmanageable number of KPIs)

#2 – Establish Flexibility

As a SaaS product manager, your worst nightmare is to have a multi-year roadmap written in stone for 1 or 2 key clients.  I’m not saying you don’t need a multi-year roadmap or a way to explain short, medium and long term initiatives to prospective and existing customers, but you need the flexibility to update that plan when necessary.  The basic idea is to let customers know that the way you’ll deliver ongoing value is to test and learn what product changes deliver better outcomes.  Which leads me to the third tip…

#3 – Be Transparent

Provide updates to clients on how you’re doing with your KPIs and what you’re learning along the way.  Present data analytics, user research insights, usability testing findings and experiment results to make sure your customers understand that the value they’re getting comes from your team’s constant efforts to improve the product to better deliver the outcomes they’re expecting.  You should be presenting this information to each customer and soliciting their ideas to achieve better outcomes at least once a quarter. You should also present your longer-term vision and strategic roadmap to get their feedback and validate they agree on the direction you’re headed. After all, SaaS customers aren’t just buying the product as it stands today - they’re also buying the future versions.

Topo Chico Lime: Why User Research Is So Important for New Products

Recently we took a trip to Whole Foods to get some groceries, and we saw cases of Topo Chico Lime stacked up near the front.  We grabbed one to try it out, and it's the last case we'll ever buy.  Why?

1. The bottles were too tall

They didn't fit on the shelf where we normally put our cold drinks, and so the fridge wouldn't close.  Since the rest of the fridge was full, there wasn't nothing to do but tilt them at an angle and hope they didn't fall out onto the floor when the door opened.

Too tall!

2. They look like beer bottles

My wife and I both work remotely and do a lot of video calls.  No big deal to drink a Topo Chico while on a call, but sip on one of these bad boys and it looks like you're drinking beer in the middle of the day.  Not so professional...

What SaaS companies can learn from the CPG industry

Imagine being the brand manager for Topo Chico Lime.  This product launch was probably many quarters in the making.  Now imagine they see some good initial numbers after the launch, then wait for a week or two and see a huge drop off.  What should she do next?

Imagine what a SaaS startup might do in this scenario - a new product launch, decent initial user volume (or trials) but no ongoing engagement, no return users.  Many companies would set up the "Engagement Entourage" to brainstorm ways to boost engagement.  More emails!  Change the onboarding experience!  The list goes on.

What does the Topo Chico Lime team do?  If they're anything like the General Mills teams I worked on, they call on their Consumer Insights person to help them understand why consumers aren't buying again.  They're setting up focus groups.  They're intercepting shoppers in stores.  They're reviewing the results from past in-home ethnographic studies.  They're analyzing data sets to identify who is buying again and who isn't.  And through this, they can uncover insights like "oh, the 20 oz bottle is too tall" and "the green bottle makes it look like beer".

What's my point? 

You have to be doing qualitative research to understand the quantitative feedback your data analytics provides.  It's such an efficient way to understand why people are behaving the way they are.

You Only Get One Chance to Make a First Impression: 3 Tips for A Great First Time User Experience

First impressions matter.  Daniel Kahneman reminds us of that in Thinking, Fast and Slow. We’re all wired to make snap judgements – maybe it’s how someone smells the first time you meet her, what the new model of a car looks like, or how a new song on the radio starts off.  If your product doesn’t make a good first impression, you’ve ruined your chance for a great relationship with that user.  So how can you make sure prospective users become users, and that they have a great first time experience?  Here are 3 suggestions:

1. Don’t neglect the discovery experience.

How did a prospective user hear about your product?  This is a critical part of the first time experience because (a) it’s where a prospective user is forming their first impression of your product and (b) it’s likely when expectations are set. Don’t underestimate the power of the smallest detail here: the marketing message you pick for an ad, a landing page hero image, the screen shots and reviews of your app in the App Store, etc.  At each step, prospects are making snap judgements on whether to continue.

Using the Jobs to be Done framework, the focus during the discovery experience should be highlighting how your product can help a prospective user do a job better than what she’s using today.  Think your budgeting app is better than spreadsheets?  Highlight that.  Want them to know that your new social network is subscription based, so there aren’t any ads? Mention it.

Let’s look at an example – an ad I saw recently on Instagram for HotelTonight.


Hmm, I usually only book hotels for work trips, and I usually plan those weeks in advance.  I don’t think this app is for me.  Also, this image is weird – why’s this guy falling into a bed at a luxury hotel?  Maybe they only work with luxury hotels…

I did not tap on Install Now…

2. Demonstrate value quickly.

During the discovery experience,  you’ve set some expectations on the value your product will provide to the user.  Now make sure you follow through on meeting those expectations by delivering value quickly – I mean within a minute, which is probably how much time a new user is going to give your product.

Let’s look at an example of how to NOT demonstrate value quickly – this is the first thing I saw when I opened the Letgo app for the first time:


Ugh, I wanted to sell some of the kids’ toys we don’t use anymore, but I can’t even see if others are posting toys and if so, for how much and whether there are people posting similar items in my area.  I literally deleted the app within 3 seconds of seeing this page because I can’t proceed without registering.

I see this all the time – forcing a user to register before she even knows what she’s gonna get for doing so.  You know what she’s going to get because you think about it every day at work for hours.  She doesn’t.  Instead, create an experience where she can explore the value of your product BEFORE committing to it.  Not doing so is the equivalent of a car dealer forcing you to buy a car the minute you walk in through the door, without a test drive or the ability to walk around the showroom and check out the different models.

Now an example of how to deliver value quickly – the Recolor app, which I found by looking through the top free apps in the App Store (discovery!).  I chose to download it because I’m always looking for new ways to unwind on the train ride home from work, and I’ve found casual games to be good. (if Recolor was on top of their Jobs to be Done game, they would hopefully uncover the insight that they’re competing with Candy Crush and staring at the ads on the El – the others ways I might pass the time on the commute home)


Within 20 seconds of opening the app, I figured out how to select a picture to color and after a brief animated interaction tutorial, I was coloring.  There’s something quite relaxing about coloring in this picture…

3. Let them know what jobs your product can help them with.

Let’s say your app has 5 features but a new user only used one as a part of her first time experience.  How would she know about the other 4 features, which might be really valuable to her?  This needs to be part of the first time experience.

Let’s look back at the Recolor app as an example of how they did this really well:



Within 5 seconds of glancing at this, I noticed a few things that taught me how Recolor works: 1. There’s an Import feature in the top right, which I immediately knew meant I could pull in my own photos and recolor them – nice, a really personal touch. 2. The headline at the top is that new pictures post in 2 hours – now I know that if I get bored of the pictures they have right now, I can come back to the app often to keep myself entertained. 3. The fact that they called out Free as a filter lets me know that I should expect to pay for some pictures at some point. 4. The bottom navigation tabs let me know the key features of the app – a library of photos to color, a gallery (of other people’s work, I presume, since there’s also a My Works tab) and an activity tracker.

Another great example of feature discovery is Amazon Alexa emails.  Every Friday, I get something like this to let me know what’s new with Alexa – this is a particularly great tactic if your product is new and changing often (don’t assume users are using your product that frequently).


Oh nice, I can hear the monologue. I love how they tell me how to activate – and use – this new skill.  


They also do an awesome job reminding me that Alexa herself can tell me about her new skills, just me asking her “Alexa, what new things can you do?”  That’s great, because I can discover and activate new skills as I’m interacting with my Echo.

EDIT: A few months after writing this post, I realized that I rarely use any Alexa skills, nor do I ever ask Alexa what new skills she's learned.  It comes down to the behavioral science of this - if I don't try this right when I read the email (which isn't always possible because I'm not in the same room as my Echo), there's no cue to remind me to try it later.  Perhaps if my Echo blinked a soothing blue light I might remember that means that Alexa has new skills.  But I never got into the habit of asking Alexa about her new skills, and I find that I ignore this weekly email.

In Summary

If there’s one thing to take away from this post it’s this: don’t neglect the first time user experience – if you don’t make a great first impression, you’ve likely lost a user forever (it’s really hard to re-engage someone who’s dismissed your product).

Agile 101: 3 Tips for Using Agile to Unlock Business Value


Agile is not a process – it’s a mindset rooted in continuous learning by observing real world human behavior.

For a long time, software was built using waterfall, a long, sequential process that requires many handoffs between product, design, engineering, and QA.  A project goes from inception to requirement gathering to design to build to test and then deployment. All that could take months, and by the time the software is released, business priorities might have changed, or users might not like what they got.

Agile aims to remedy this by putting software into the hands of users faster and then measuring whether the changes are delivering the expected business outcomes.  If so, great, keep improving on what you have.  If not, no worries – you learned something about why not, and you only invested a few weeks to gain that insight.

Switching from waterfall to Agile isn’t easy.  But here are some tips to keep in mind.

Tip 1: Know the Roles

This is your “squad”:

Product Owner

The person responsible for ensuring the squad is constantly delivering business value through the product. This person often translates and prioritizes ideas from “the business” (CEO, strategy team, sales, marketing, etc) and customers for the squad who is actually producing the software.


The folks who do most of the building – focused on how to deliver business value from a technical implementation perspective.


The people who test changes before they go to users.  Testing strategies fall into 2 main categories: manual and automated, with much emphasis on automation as a more scalable/risk-reducing strategy.


These folks translate stories into user journeys/experiences.  Typically they’re sharing their ideas via wireframes (for User Experience or UX designers) or visual comps (for User Interface or UI designers).

Scrum Master

This person’s role is to ensure the squad is efficiently and consistently delivering business value.  He or she will schedule all ceremonies (see below).

Subject Matter Experts

Not required, but sometimes it’s helpful to have SMEs on the squad to answer complex questions (for example, if you operate in a heavily regulated industry, you might want someone from compliance on the squad to approve changes quickly).

Tip #2: Commit to Frequent Production Releases

A key output of the process is shippable software.  It’s important to make always ship to production at the end of a sprint because:

  • Go/no-go meetings to decide whether to ship are painful and time-consuming.  More often than not, you’ll feel like you’re not ready and postpone, never knowing if you’re spending more time on something that’s not even going to deliver the business outcomes you’re expecting it to.  Shipping often lets you get feedback (qualitative or quantitative) from real users and eliminates the time needed for release planning (you always release).
  • The deadline creates a powerful forcing function.  As the sprint end date nears, the squad is forced to make scoping decisions and rally as a team to ensure there’s something to ship.

Most teams use 1, 2 or 3 week sprints to dictate how often they ship to production.

Tip #3: Follow the Ceremonies

There are only 5 meetings that should happen every sprint:

Backlog Grooming

A weekly hour-long session where the top of the backlog is discussed and estimated by the squad.  Prior to this meeting, the product owner should prioritize the backlog such that the top items represent the most meaningful ideas to deliver business value / move the product KPIs.

During the meeting, the product owner should present each ticket, starting with the top of the backlog and the Scrum Master should ask the squad to estimate (I prefer estimating via planning poker because it eliminates any bias in estimates but there are other techniques).  I’ve found asking for an estimate is the best way to force clarifying questions to come up from squad members – things like what users will this impact, what browsers are included, how will we know if we’ve succeeded (tie the story back to a KPI), etc.  Anything to clarify the scope of the story or what needs to be true in order to be successful.

Spring Planning

Assuming the top of your backlog is estimated, sprint planning is where the Scrum Master asks the squad to make a commitment to delivering specific stories/bugs in the next sprint.  Ideally the squad is just determining how much of the top of the backlog they think they can take on, but there might be scenarios where new items that were not discussed in the last backlog grooming are estimated.

Key questions to ask during this meeting:

  • How much did we take on last sprint?  Did it feel like too much? Too little? Just right?
  • Are there any other factors in this sprint we should consider?  Considerable unknowns with some of the work?  Production support spikes we might anticipate?  Planned squad member vacations?

At the end of the meeting, the commitment should be clear to all, and the sprint should begin.  The product owner may want to communicate the commitment to stakeholders.

Daily Standup

This is a daily 10-15 minute meeting, typically in the morning but as long as it’s the same time every day, any time is fine.  Each squad member should answer the following questions:

  • What did you do yesterday?
  • What are you planning to do today?
  • What’s blocking you from doing what you planned to do today? (for example: I got pulled into a lot of meetings related to some other project at the company, I can’t test because the environment is down, I don’t understand what we’re trying to do, etc.)

Other squad members should listen for blockers in particular, but also items that might require some collaboration (for example: “oh, you’re working on that? I had some ideas, I’ll find you after standup”).  Scrum Masters should be making sure the squad is on track to deliver their sprint commitment (burn down charts are helpful for this) and that there is a game plan to remove any blockers that day.


This is typically a 30-60 minute session open to the squad and all stakeholders to see what was shipped that sprint.  Squad members (including technology) should demo the changes, perhaps providing some color commentary or “behind the scenes” on what it took to implement.  This is a great place to test squad communication  – anyone should be able to get up at the showcase and explain the background/rationale for the change, along with demoing it.

After or during this meeting, stakeholders should provide feedback to the product owner. (ex. “looks great”, “wait, I didn’t realize that’s what we were gonna build – tell me more”, etc.).


This is typically a 30 minute meeting for the squad between the showcase and sprint planning.  The outcome of this session is to identify from a process perspective, what went well that sprint and what could be improved.  There are a few ways to do this:

  • Go around the room and ask each squad member what went well and what they would change
  • Ask folks to fill out a short form before this meeting, then identify themes and discuss
  • Ask the team to write down what went well on Post-Its and put them up on a wall.  Then do the same for what could be better and discuss each Post-It afterwards
  • Bring up the sprint burndown chart and discuss whether it looks right (ideally you’re claiming points evenly throughout the sprint – something is wrong if it looks like a cliff where all points are claimed on the last day of the sprint)

I’d recommend switching up the format of this ceremony periodically (not necessarily ever sprint) to keep this meeting fresh.

Another key part of the retrospective is addressing the feedback that comes up - if needed, create action items with owners and deadlines and allocate time in the next sprint.  Nothing deflates the value of a retrospective than a feeling from the squad that things aren't getting better.

It’s really tempting to skip these ceremonies because “it feels like a lot of meetings” but if you’re doing them right, they’ll go by fast and you’ll understand the value of them.

How Jobs To Be Done Can Help You Get More Users To Switch To Your Product Or Service

If the concept behind Jobs To Be Done wasn’t real, we’d all drive the exact same car.

Jobs To Be Done (JTBD) is a relatively new framework for thinking about the value of your product.  The ideas is that people hire and fire companies to do a certain job for them, and that there is always an existing solution for doing that job.  Think of it like this, the job we hire a car to do is to get us from point A to B in a reasonable amount of time.  But if that was true, why are there so many makes and models of cars?  Because that’s not the real job to be done by a car – every car can do that.  Maybe for the wealthy, the job is looking good in public (luxury cars) or for parents the job is protecting their kids (safe minivans/SUVs) or for single guys the job is attracting women (sports cars).   JTBD aims to uncover these true motivations.

Here are 3 key differences between JTBD and traditional user research.

1. Recruiting

JTBD suggests talking to people who have hired or fired your product or service within the past 90 days, when the decision is still fresh in their mind.  This narrows down the number of people who will fit the bill, and if you’re a startup with no users yet (or no product), then you’ll have to talk to users who have hired or fired your competitors.  (which is a good way to validate who you’re competing with)

2. The Process of Uncovering Why

A JTBD interview is designed to uncover the story of how the person came to decide to hire or fire a product or service, and how it’s gone since making the decision.  See this template below:


The general idea is to build a timeline from when the user first thought about changing solutions, to how she decided on a solution, to how she purchased the new solution, to how it’s going since purchase.

3. The Deliverables

In addition to developing the timeline above, the other outcomes of a JTBD interview will be

  • determining what the job is to be done (ex. for luxury cars, getting around town in style and comfortably, perhaps)
  • understanding the 4 forces that drove the user to make her decision and later evaluate that decision.  Specifically:

The idea here is to understand what’s prompting the user to think about changing from her current solution (for example, a pain point with the existing solution or a trusted source introducing an alternate solution), what’s attracting her to the new solution (hopefully yours), what worries her about switching, and what’s preventing her from making the switch?

Using this information can be very powerful, especially when marketing a new product. Just make sure to be explicit about how your product/solution is better than the current solutions people tell you they’re switching from.

Replacing Product Visions with Customer Journey Visions

Homer Simpson car vision:  The Homer

Homer Simpson car vision: The Homer

Where do you see the product in X years?

The product vision exists to answer this question.  It helps communicate a sense of direction to stakeholders, both internal and external.  It’s often accompanied with mockups that took a lot of time to create.

The Issue with Product Visions

But is asking what the product looks like in 3 years even important?  To me, no way.  Product visions are a self-fulfilling prophecy.  They’re created by product leads who will want to make sure they move the product closer to their vision over time so they won’t look like they (a) don’t know how to predict the future, (b) can’t execute or (c) are bad product managers.  So they iterate towards that vision, regardless of whether it’s the right direction.  At least it’s a direction that stakeholders are familiar with, they think.

An Alternative Vision

So what is a product lead to communicate if not a product vision? To me, the best way to communicate a sense of direction to stakeholders is to help them imagine what the customer’s world will be like if the product is successful.  What do I mean by that?  Let’s look at some imaginary examples:


Product Vision
A cross-platform shopping experience that lets customers search, compare and order millions of items by voice.

Customer Journey Vision
Imagine never having to leave your house again to go to the store.  No more parking lots, no more lines at the register.  Imagine ordering items from your sofa and opening your front door an hour later to see them there.


Product Vision
A self-driving car with free WiFi that can be charged in less than 15 minutes.

Customer Journey Vision
Imagine being able to check email and read the news while your car drives you to work each morning.  Imagine reducing your carbon footprint and saving money on gas in a luxury, high-tech automobile.

Blue Apron

Product Vision
A flexible subscription, in-home cooking service with a mobile app that uses AI to recommend meals to customers.

Customer Journey Vision
Imagine not having to think about what to make for dinner.  Imagine everything you need to make a gourmet dinner in 30 minutes shows up at your doorstep each week.

The Homer

Product Vision
“Powerful like a gorilla, yet soft and yielding like a Nerf ball.”
A bubble dome car that can hold huge beverages and plays La Cucaracha when you honk.

Customer Journey Vision
Imagine being able to honk many horns when you’re mad.  Imagine being able to shut out screaming kids on road trips with the push of a button.

How to CREATE Experiences that Spur Users to Action



I worked with Dr. Steve Wendel, who is our Head of Behavioral Science.  He literally wrote the book on designing software for behavior change.  In that book he outlines his CREATE frameworkthat suggests there are 5 hurdles you need to overcome to get a user or prospective user to take an action, and that at each hurdle, you’re going to lose a few people (hence the funnel shape).  Let’s take a look at the funnel in greater detail.


You’ve gotta prompt your user to take the action you want – be it an email, push notification, or ad.  This is the one I think most product development squads forget.  They focus so much on building a great user experience that they forget how and why the user would come to their product in the first place.  (if you build it, they will NOT come)


As you may have read in books like Blink, our minds use shortcuts to make instantaneous judgements in response to a cue.  You should be aware of how your audience might react to your cue.  For example, if you’re telling them you have the greatest budgeting app in the world, be aware of what people think about the word “budget” (mostly negative reactions, as it implies work or an unpleasant realization that they’re spending too much).


If you can get past the knee-jerk emotional response, then you have to get past a more rational cost-benefit evaluation.  If you’re asking them to switch to your product, this is the point in time in the Jobs to be Done framework where they might decide whether your product is superior to what they’re using today, and whether the switching costs will be worth it.


Your audience has to have the ability to take the action you’re asking them to take.  For example, if you send an email asking them to log in to your app and check on some changes but they’re in a cellular dead zone on the subway, they’re not logging in then (and chances are, they’re not going to remember to log in later, unless they open that email again).


Which brings us to the last step – even if the person can take the action, you have to convince them why NOW is the time to do so.  For example, in my line of work, getting younger employees to save for retirement is hard – there are more immediate financial goals like buying a house or paying off student loans that feel more urgent that something that’s 30 years away.

Here are a couple behavioral techniques that can help create urgency:

  • Scarcity: you might have seen Amazon do this with a message like “only 3 left in stock” under a product’s description.  Or with a limited number of beta invites for an upcoming app launch.
  • Deadlines: you may have seen this on TicketMaster – a clock that counts down saying that the price for those Bieber tickets you’re thinking about buying will only stay locked in for 3 more minutes.  Same idea with limited time offers.


This one is not on the visual, but the last step is actually taking the action.  This is where you give your user a virtual high five for taking an action that you both wanted her to.

Why Agile and Roadmaps Don't Mix

I’ve worked in Agile for 6 years now, having worked in waterfall at Accenture for 5 years prior to that. I’ve presented dozens of roadmaps. But now I’m on a mission to kill the phrase “roadmap”, at least internally, at work. Why? Because roadmaps and Agile don’t mix. Allow me to explain.

The Visualization

Ever presented a roadmap that looks like this?


Of course you have. And when you do, your stakeholders see a Gantt chart/project plan. If you’re using agile, you probably used some rough estimation to come up with the timeline. Yet the visualization makes it hard to convey the uncertainty around the timeline. No matter how many asterisks you put on the slide, they will see this as a project plan.

The Expectations

So your stakeholders see this “project plan.” What do they expect? For you to deliver on it! They judge you, your squad, your parents, your value to the company on your ability to “stick to the plan”. But is delivering features “on schedule” really success? No way. High fives for delivering software features on time/on budget should be left in 2002 with waterfall.

What happens when you’re delayed? When great business opportunities present themselves? When you realize you want to iterate more on something based on feedback? You have to update your “project plan”. Bummer. Everyone was really excited about that thing at the end of your roadmap. Clients were expecting it. Senior execs built revenue projections off it. Someone from customer service Tweeted that it’s coming. Now they’re all scrambling to save face. And they hate you, product manager, for not doing your job! 

And you thought it’d be OK to update the roadmap because that’s the point of Agile right?

better Alternatives

There are a few alternatives I prefer to the Gantt chart roadmap:

1. Gantt Chart with Buffer

This is a minor tweak to the "project plan" view but at least have some buffer depicted on the roadmap.  Perhaps some empty months with a dotted box outline and a "?" suggesting that the teams need to reserve time for things like responding to customer feedback, production bugs, and new opportunities.

2. Kanban Style

Kanban boards are used to show the status of different work items (in the roadmap context, those would be research/validation work, design, or development).  You don't have to lose the timeline context on these boards - you can still indicate an ETA for each item so people have a general sense of when it'll be available (I'd use quarters instead of a specific month to provide flexibility).  Here's an example Trello board for Chuckwagon, an imaginary app that saves you time in picking recipes to make at home, grocery shopping and cooking:

Screen Shot 2018-04-12 at 12.21.58 PM.png

A couple things to note:

  • Ideas are being validated before they go into the design/build queue.  In this case, the Group Meal Plan ideas was scrapped because users didn't think their friends and family would want to make the same recipes as them.
  • Once released, there's analysis being done to identify whether a change is improving the KPI it was intended to improve.  In this case, the Waitlist Landing Page improved the acquisition KPI because it's collecting email addresses of potential users but the social sharing feature didn't, because few people ended up sharing the landing page link via Facebook, Twitter or LinkedIn.  By doing this analysis we're able to constantly learn and make sure the focus of the product development squads is on outcomes, not just output.

Microsoft also uses this concept for their public Office365 roadmap, although they don't use the same visual layout:

Screen Shot 2018-04-12 at 12.29.46 PM.png

3. Time Horizons

Here's an example from Slack's platform team that shows items bucketed by near term, mid term and long term, with no specific mention of what those "terms" mean.

Screen Shot 2018-04-12 at 12.32.28 PM.png


I like the Kanban style roadmap myself, because it provides a quick view of what's happening in product development but doesn't lose sight of outcomes and learnings.