#5Things in Product Management for September 8, 2017

Over the last couple of weeks, I’ve been focusing on building the MVP for my social selling tool Sharey. Particularly, I am digging into the product vision, and my strategy to get there. This week’s #5Things post focuses on product vision, strategy, roadmaps and how important it is for each of these things to be in alignment.

Product Vision

A good product strategy comes from a strong product vision. As Marty Cagan puts it in Vision vs. Strategy

The product vision describes the future we are trying to create, typically somewhere between 2 and 5 years out.  For hardware or device-centric companies it’s usually 5-10 years out.  This is not in any sense a spec; it’s really a persuasive piece.  It might be in the form of a story board, or a narrative like a white paper, or a prototype (referred to as a “visiontype”).  It’s primary purpose is to communicate this vision and inspire the teams (and investors and partners) to want to help make this vision a reality.

If you’re tasked with creating the product vision, take a look at these ten questions you can ask yourself to help draft your vision statement.

Answering these questions will help organize your vision into documented thoughts:

  1. What problem does my organization seek to solve?
  2. Why do I believe this problem needs to be addressed?
  3. Does this problem matter to other people
  4. Do I honestly believe we have the answer to that problem? (elaborate)
  5. What changes do I believe my organization can affect?
  6. What are the greatest strengths of my organization?
  7. What is my dream for this organization?
  8. How would things be different if my dream came true?
  9. Does my dream connect on a personal level with others?

Product Strategy

Having a vision is great but you need to also develop a strategy to realize it. According to Mark Andreessen, as a startup, the only thing that matters is determining “product-market fit” I read this article years ago and it was really great to revisit it. If you’ve read it before, read it again. He states that the market is more important than the team or the product.

 [The] market is the most important factor in a startup’s success or failure.


In a great market — a market with lots of real potential customers — the market pulls product out of the startup.

The market needs to be fulfilled and the market will be fulfilled, by the first viable product that comes along.

The product doesn’t need to be great; it just has to basically work. And, the market doesn’t care how good the team is, as long as the team can produce that viable product.

In short, customers are knocking down your door to get the product; the main goal is to actually answer the phone and respond to all the emails from people who want to buy.

And when you have a great market, the team is remarkably easy to upgrade on the fly.

I’ve used the Lean Canvas outlined in the book “Running Lean” to help me model my startup. It was originally based on the Business Model Canvas. I’m reading a beautifully illustrated book now called “Business Model Generation” that goes pretty deep into how to create these canvases using a ton of examples.


Only after you’ve developed your product vision and strategy can you begin to lay out your product roadmap. In this next post from User Voice, Cliff Gilley of The Clever PM cautions against building feature based roadmaps. Instead, he suggests that your roadmap gets fuzzier the further out you go.

I generally advise people to use some systemic approach like the following, stated clearly within the roadmap presentation or even directly on the roadmap slide/graphic/visualization itself:

  • 0-1 month = Work in Progress = We know this will be delivered, and can use data-driven projections to provide a high level of certainty on delivery times. Rough confidence level is 90%.

  • 2-3 months = Committed Work = We know what we currently view as the priorities on the backlog, and have broad estimates that allow us to predict likely delivery, subject to future discoveries. Rough confidence level is 75%

  • 3-6 months = Tactical Plan = We have a strong idea of the themes that we want to tackle in this time frame and are actively engaged in problem definition and solution proposals that will be estimated and backlogged. Rough confidence level is 50%.

  • 6-12 months = Strategic Plan = We have a set of thematic goals that we believe are likely to be important to delivering on the stated strategies of the company, but have not moved to problem definition or solution proposals. Rough confidence level is 25%.

  • 12+ months = Vision = We are setting thematic areas that we believe will be valuable to bring our vision of the future into being, but have not engaged in full customer discovery, problem definition, or solution proposals. Rough confidence level is 10%.

That’s this weeks #5Things in Product Management. Have a great weekend.

Does your app save content offline? Humanize your filenames.

I am on a quest to help UX designers think about humanizing their products. In this post I’d like to talk about humanizing filenames when your application saves an invoice.

Any application that bills it’s customers should have a human readable file name. Your customers need those invoices when they submit expense reports. It’s frustrating to have a folder full of poorly named files when you are trying to find a specific invoice.

I’d like to use Buffer to demonstrate my point. Buffer is an awesome app that has a great user interface. It’s the contrast between a normally great UI and it’s in-human invoice file names that illustrates the problem.

Download an Invoice

The download UI is below. When you click on either Download Invoice as PDF or Download Receipt as PDF a file is dropped into your download folder.

UX issue with save file

Anyone see a problem here?

The receipt filenames are woefully unhelpful. It’s very obvious what is going on here. The developer who wrote this code probably had the requirement that each receipt filename should be unique.

Come tax time I’m going to have a folder full of these poorly named files. I will either need to rename them all or manually check each file to see if it includes the correct months. It’s not such a big deal with Buffer since my invoices are all the same amount. I would rip my hair out in frustration if I had to manually match different invoice amounts with the appropriate file.

This is an easy problem to solve by adopting the following naming convention.

Do this instead

application – receipt – YEAR-MO – unique ID.pdf

So, in the example above Buffer should name the files

buffer - receipt - 2017-01 - BHz7Z.pdf
buffer - receipt - 2017-02 - AMz7Z.pdf
buffer - receipt - 2017-03 - aLz7Z.pdf
buffer - receipt - 2017-04 - Ajz7Z.pdf

Humanizing information removes cognitive friction in your application. If you allow users to save files offline, make sure that the filenames are as useful to them as the rest of your product.


Humanize Your Data

I’ve been playing around a lot with the app Rescue Time, it’s a really cool productivity tool that helps keep your workday focused. I’ve used it for a number of years.

Today, I was taking a look at some of my stats and came across this pretty cool statistic.

Wow, I’ve been productive for over 5 thousand hours. Wait, how long is that? Is that a year? So I popped on over to a time conversion website and plugged the data in.

It turns out, it was about 31 weeks out of a total of 49 weeks logged. This data meant a lot more to me then pure hours. I took that information and plunked it into a mockup.

This simple change makes the data so much more consumable.

So, the lesson here my friends is look at the data you present to your users. If they have to do math in their head you need to simplify things for them.

Rock on


Philly Tech Week 2017 Talk

Thanks everyone that came out to my Philly Tech Week 2017 talk – What failing a Ninja Aptitude Test Taught Me About Product. Below is a copy of the slide deck.

3 Things I Learned About Usability Testing By Looking at Customers in Their Underwear

How resistance can get in the way of qualitative insights

“Please strip down to your underwear now,” I heard myself say. I tried to act casual about the situation I was in but the fact is, I felt pretty uncomfortable. When the middle-aged man walked back out of the dressing room, I was going to wrap a tape measure around his naked mid-section.

As a product manager for a technology company, you wouldn’t expect this task to be in my job description.

I’d been measuring people of all shapes and sizes for several hours. They were all there because they had answered an ad I put on Craigslist:

Wanted: Men and women over the age of 18 for a research study in the apparel industry. Please wear loose fitting clothing. Must be willing to strip down to underwear. Pizza will be served. Compensation: $25.

Being a naturally shy person, this was definitely outside of my comfort zone.

Resistance is a frenemy

Now, let me pause for a moment and introduce my buddy Resistance to the party. Oh, have you already met? I’ll bet you have.

Resistance often keeps us from talking to customers. Now, keep in mind that he has good reasons for what he does. He wants to protect us. He wants to keep us out of uncomfortable situations. Or he reminds us that we have so many other things to do … certainly we can find out everything we need to know from a survey. Turns out, Resistance is often more frenemy than friend. (And in the credit-where-credit-is-due department, let me say that author Stephen Pressfield is responsible for the concept of personifying Resistance in this way.)

Back in my days with the apparel company, the inescapable fact was that I needed try our fit-testing body scanner on real humans. I was forced to tell Resistance to beat it and push through my uneasiness. The result was that I ended up with loads of information we never would’ve had if we hadn’t brought in outside people.

What product managers should remember

Today, working for an email marketing company, I rarely have to ask people to strip down to their underwear to test out a product. That certainly makes talking to customers a whole lot easier.

Still, that awkward experience from many years ago taught me several important things about usability testing. Three of the most important are:

1. For a nominal fee and a slice of pizza, people will get nearly naked for you. Who knew? I certainly didn’t when I placed that Craigslist ad.

But the larger point is this: It’s not as hard as you might think to get customer feedback.

People generally like to be asked for their opinions. Don’t be afraid to reach out to customers. Not everyone will have time for you, but plenty of them will.

Today, instead of Craigslist and pizza, we use a screener in our application and offer participants a $25 Amazon gift card.

2. People are squishy. Data is not. Quantitative data is a great starting point, but it’s no substitute qualitative data.

During our fit testing experiment, we had one guy come in who swore he had a 32” waist. Our measurements said otherwise – he was closer to a 36. We soon figured out that he’d been stuffing himself into 32s even though they were much too small. Had we simply surveyed this man, we would’ve put him down as a 32. Because the human body is squishy, people could report all kinds of misinformation.

Human behavior can be squishy, too. People may report that they use your software a certain way, but you won’t know for sure until you find out for yourself.

Now, we start with quantitative data from analytics platforms like KISSmetrics and then we dig deeper with interviews.

3. If you’re making products for humans, you need to make human connections. With so many things competing for your time, talking to customers may feel like it’s not time well-spent. However, with just a conversation or two, you may discover an unexpected insight. You don’t know what you don’t know.

Just last week I was speaking to a long-time customer about a new product feature we’re developing. In the course of the conversation I had an epiphany: He’s not going to use this great new feature unless it works with his entire external ecosystem that he’s spent years developing. That put our plans into a whole different perspective for me.

It’s these types of insights that can only come from making a personal connection with someone.

Listen, I know I’m probably not telling you anything you don’t already know. But knowing it and doing it are two different things. We all know that we should eat right and exercise, too, but a booming diet industry is proof that not everyone follows that advice.

I promise you, blocking out even two hours to talk to customers can yield insights that you’ll incorporate for the next year. So if you’re a product manager, or if you’re involved in developing new products in any way, give Resistance his walking papers – or at least give him an afternoon off.

#5Things in #ProdMgmt for November 18th, 2016

Hi everyone, it’s time for another #5Things in product management. I’ve tweeted a lot of great product management articles this week. Here are some a few of the best ones that I’ve found.

Are you working in a feature factory? This post from @JohnCutlefish helps you sort it out. My favorite test?

Infrequent (acknowledged) failures and scrapped work. No removed features. Primary measure of success is delivered features, not delivered outcomes. Work is rarely discarded in light of data and learning. Often the team lacks the prerequisite safety to admit misfires

read more at hackernoon.com

If you think that the Agile framework will manage risks for you, you’re headed for a big wake up call…

Agile is Not a Risk Management Approach

Some people believe agile approaches with their short cycles and regular feedback have a risk management approach naturally built into the process. It is easy to see why, the building blocks and attachment points for plugging in an effective risk management process are certainly present, but unfortunately just building something iteratively or incrementally does not ensure risks are managed.

read more at leadinganswers.typepad.com

@TheCleverPM thinks that the hardest part of product management is dealing with humans…

A big part of our jobs as Product Managers is to lead through influence, and this means that we have to convince others of the direction that we want to take.  And this can be really hard.  Everyone in our organization has a different spin on the product, the strategy, the company, the culture — and often these only truly “mesh” at their core, with the radiating effects or impacts of these goals pushing us in a wide variety of directions.  Add to this the fact that different people learn, think, and decide through different paths makes it even harder.  We need to take time as Product Managers to understand how it is that the influencers in our company do these things, and when, where, and how we should approach them in order to move things forward.  Some people respond to data, others to emotional appeals, and still others strictly on financial motivations — we must know who is swayed by what appeals, and use those to our advantage on a daily basis.

read more at cleverpm.com

@CayenneApps offers seven reasons to use SWOT analysis when developing your strategy…

Did you know that SWOT analysis is more than fifty years old? New methods come and go, but hundreds of thousands of businesses around the world still trust SWOT. Why is it that the framework developed in the 60′ still stands bravely, invariably finding new supporters in such a volatile business world, where the landscape is constantly changing?

There are of course many reasons — some of them more abstract, and some more specific to certain types of ventures. Here you can find our Golden Seven — an opinionated list of the SWOT features, which make it so useful for every business.

read more at blog.cayenneapps.com

Something to think about…

The most important thing in communication is hearing what isn’t said.

– Peter Drucker

If you like these product management nuggets then please share it with your product management friends.

Have any suggestions for how I can improve this? Just send a tweet to @JoeCotellese and put #5Things in the message so I can find it.