Replacing Product Visions with Customer Visions

Homer Simpson’s 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 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 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 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 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.

Want to discuss your vision?

Contact Me

3 Tips for Managing a B2B2C Product

Managing a B2B2C product is like working for an auto manufacturer: you sell cars to dealers, who sell to consumers.

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.  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 proposal 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, as I’ve written about before, don’t pick more than 2 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.  I wrote about an alternative to Gantt-chart-style roadmaps previously, but 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.

Want to talk more about managing a B2B2C product?

Email me or schedule a call.

If You Build It They Will NOT Come

So you’ve got a great idea, and you’ve vetted it using the 4 steps I previously wrote about.  Now what?

Build an Audience, Not a Product

Many entrepreneurs (myself included) will jump immediately to building a prototype or alpha version of a product.  They’re starting at the end of the conversion funnel – focusing on the user experience and ignoring the critical initial steps in a user acquisition funnel: marketing.  What’s going to prompt people to use the product? How will they hear about it? How will you convince them to try it? (not sure? see How Jobs To Be Done Can Help You Get More Users To Switch To Your Product Or Service).


Please don’t build something before you know how people will discover it.  Please.

This isn’t just my advice: read about Product Hunt founder Ryan Hoover’s take on this.

Instead, I’d recommend testing the marketing campaigns to validate user acquisition costs that could to make sure your business model is realistic.  Many startups fail because they run out of cash, and marketing expenses, especially when you first launch, can really drain your bank account.

Testing Marketing Messages

For a few hundred dollars, you can start running ads in a few days to test your user acquisition costs.  Try running ads on LinkedIn (if you’re targeting a professional or enterprise customer), Facebook, or Instagram (not sure how to run an ad? Mailchimp, one of my favorite digital marketing platforms, can help).  I’m not a fan of Twitter because setting up and analyzing results from ads is painful, but they do offer one unique feature: the ability to target people based on what apps they have installed on their phone.

Build a Landing Page to Collect Emails

So where do you send all the people who click on an ad? Build a simple landing page that explains your product using words and pictures.  Ask people to give you their email address to get updates, and then send periodic (monthly or bi-monthly would be fine) updates on how things are going.  Or write content they’d be interested in and include that in a periodic newsletter.  Track opens and clicks.  These are your early adopters and they’re likely to volunteer to beta test your product if you do build it.

If they’re not willing to give you their email address, why should you think they’d sign up for your product?

Here’s an example landing page I’m building for an idea I’m working on:

alpha landing page design

I built it in an hour on Lander and before I even launched it, I ran some usability tests to see how people would react to it.  That way, I can tweak the page before running ads so that I can convince more people to provide their email and therefore lower my user acquisition costs.

Want to talk about building an audience for your idea?

Email me:

How to Recruit User Research Participants from Craigslist

Consistent communications with users is critical for successful products

Talking to your users should be a consistent part of your product development process, no matter what the stage.  Don’t ever assume you know how people will respond to what you’re doing – humans are complex creatures.  When vetting an idea, it’s a great way to confirm that your solution will be different, and that the problem you’re trying to solve really exists in the world.  When launching, it’s a great way to gauge reactions to user acquisition campaigns/ads as well as your first-time user experience.  When growing, it’s a critical way to ensure your tactics will scale to large audiences.

So how do you recruit people to interview for their insights and feedback?  There are a lot of options, such as and

But in this post, I’m going to describe a low-cost and perhaps the fastest way to recruit: Craigslist.

Posting a Gig

  1. Pick a city to post in.  If you’re looking to recruit for an in-person interview, post locally or in the cities where you’re willing to go to.
  2. Create a post in the “gigs” section.  I typically choose the “computer gigs” category but you can experiment with others.
  3. Describe who you’re looking to talk to and what you’re asking them to do.
  4. Provide an incentive in both the description and the “pay” input field on the Craigslist form.

Here’s an example from a recent post I made:

Screen Shot 2017-08-31 at 9.37.25 AM

Some Things to Keep In Mind

  1. Keep in mind some biases that Craigslist will introduce to your participant pool: location (because you had to pick a city or multiple cities to post this to) and where you posted this.  For example, I posted the above in the “computer
  2. I find that more people respond when I post the gig to “computer gigs” (vs other categories like creative or writing).
  3. I find that most people respond to these gigs at night, so expect at least one day turnaround for starting the recruiting process.
  4. Craigslist doesn’t allow  you post links to screener surveys in the post (I used to use a Google Form to filter out people who didn’t meet the criteria of who I wanted to talk to) so make sure you’re clear in your posting what the requirements are.  You might get some fakers still email you, so you might want to think of ways to filter them out before scheduling an interview.
  5. If you feel like you’re not getting enough responses, consider increasing your incentive.  A high level of compensation is $1 per minute of time you’re asking them for, but I’d suggest starting a little lower at first as very few people make $60/hour.
  6. Don’t forget to factor in no-shows.  For example, I posted a gig like the one below in 5-6 cities and in the course of a week, I had 20 interviews scheduled. Only 6 people (30%) actually showed up, even after accepting the meeting invite.  I’d recommend following up the day before or the morning of to confirm they’re coming and remind them of the incentive.

Some Example Results

I posted this ad in both Austin and Craigslist as I’m trying some new meeting scheduling tools.  I had 7 interviews on my calendar within 2 hours!

Screen Shot 2017-10-03 at 5.25.41 PM

Want help recruiting user research participants, or any other parts of the user research process?

Email me:

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

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.

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.

Want to talk more about Agile?

There’s no way this one post can do Agile justice.  To talk more about how you can unlock the power of Agile for your business, please either email me or schedule a free 30-minute call.

Capturing Customer Insights for Your Squad

Not everyone from the squad (design, engineering, QA) may be there when you talk to customers. So how do capture insights to share what you learned with them?

My vote is the Job Story and I feel this article does a great job explaining it.  A Job Story summarizes key insights way better than an audio recording or written notes.

Let’s write an example job story from my experience in FinTech: planning for retirement.

When I start a new job, I want guidance in selecting my 401k contribution rate, so that I can feel confident about my decision, finish my HR paperwork and get to work! 

Let’s look at each clause in further detail.

The When Clause

This is perhaps the most critical part – it provides important information about the context in which the person is trying to do a job. Some key questions to ask when writing this:

  • What’s prompted the person to think about doing this job? (In the CREATE framework I wrote about previously, this is the cue). In this example the cue was probably filling out some HR paperwork.
  • Where is the person when the cue occurs? As you might imagine things like whether this person is at home, at work, or on the road would be important. Do they have a computer nearby? Or just a phone?

In the example above, if I had just talked to a new hire about their journey to make this decision, I might refine my when clause:

When I’m sitting in my first day HR orientation and am asked to fill out paperwork about how much I want to contribute to my 401k…

The I Want Clause

This is where you explain the job to be done. In this case, it’s deciding how much to save for retirement. Note that I intentionally didn’t specify a solution – no mention that we should show something like “you’d have $50,000 per year if you saved 5% and $70,000 per year if you saved 7%” or “to max out your employer match you should contribute 6%”.  I’m not saying you can’t suggest solutions when reviewing the story with your squad, but I’m a big believer that product managers should be presenting problems, not solutions.

In this example, as the squad starts brainstorming possible solutions, they may come up with either a tool to explore the implications of different contribution rates or an engine that just spits out a recommendation with an explanation. Both solutions might work for the person.

The So That Clause

This is where you explain why it’s important to the person to complete this job.

In this example, it’s important to note that for this person, they want to make a good decision but the real goal is to get through the paperwork and start the role she was hired to do. There might have been other reasons the person wanted to do that job:

…So that I can retire as soon as possible (he doesn’t like working!)

…So that I can minimize my annual tax bill (trying to lower her take home income)

Think about how different the squad might interpret the story based on the way it’s written.

Don’t forget the emotional and social aspects

Every job story has 3 components:

  1. Functional
  2. Emotional
  3. Social

I’ve only written about the functional here to start: what is the person trying to do? It’s important to consider the other two aspects though.

Emotional. How does the person feel before, during, and after they’re doing this job in their life? In this example, we know that doubt is a prominent feeling when retirement planning; no one is really sure when planning for something that might feel so far away.

Social. Will others know that the person has done this job? Will they discuss it openly? What will others think about the person based on how they did this job? In this example, we know it’s not common to discuss your 401k contribution rate with others. Maybe part of the solution is to make it easy to share your contribution decision anonymously within the company or to publish anonymous data from HR so new hires know what others have done in the past.

Want to talk more about how your team is collecting, documenting and using customer insights? Drop me a line. 

Why You Should Design Experiences Like Real World Conversations

Does your digital experience feel like a real world conversation?

Yesterday Michaela Hackner, Head of Content Strategy at Capital One, came to talk to us at work about how they’ve used content strategy to improve their user experiences and business outcomes.  She also mentioned that her team is part of the Conversation Design and that they design interactions using “talk bubbles” to imagine what the back-and-forth between C1 and the user will be, as if the person had walked into a retail branch (or in this case, was talking to Alexa).

It got me thinking to how great digital experiences mimic great real-world interactions – they all start with a conversation.  A common place I see startups failing with this is asking users to register before demonstrating value or even understanding what the user is trying to accomplish.  Don’t assume this person read your entire marketing site or your app’s entire description in the App Store or Google Play.

I’ve written about this before (with the shame-on-you example being LetGo).  Asking me to register before even understanding what I’m registering for or the value to me of registering is like:

  • A car salesman asking you to fill out a customer lead form the minute you walk into a dealership, before he greets you or you even tell him why you’re there
  • Asking for my credit card as soon as I walk into a retail store, even if I’m just browsing
  • A banker shaking my hand and immediately asking me for my Social Security Number and address so he can open a new account for me, without even trying to understand why I might be interested in a new account

Instead, imagine if you had a retail store – how would you train your employees to greet a prospective customer when he/she walks in the door?  What types of questions or responses would you expect?  Start there and see how much better the user feedback and business outcomes can be.

Want to talk about making your user experience more conversational?