Joe Cotellese | Learn Product Management

.+Add.Feed Info1000FOLLOWERS

Do you want to become a better product manager? Come visit my site and learn how. My specialities are in product management and product marketing with a focus on agile development, product lifecycle management, build vs. buy analysis, business models, product requirements documents and interaction design.

Happy Friday! Welcome to another installment of #5Things in Product Management. Here’s some of the things I’ve been thinking about and reading in the world of product management this week.

I’m building a startup right now and am thinking alot about Product Market Fit. This great article from @chrija dives into it in “WTF is PMF?

The problem with PMF is that it’s hard to precisely define and even harder to measure. So difficult, in fact, that I’ve heard several people resort to the “I know it when I see it” phrase (famously used by a Supreme Court justice to define pornopgraphy).

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.

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

What problem does my organization seek to solve?

Why do I believe this problem needs to be addressed?

Does this problem matter to other people

Do I honestly believe we have the answer to that problem? (elaborate)

What changes do I believe my organization can affect?

What are the greatest strengths of my organization?

What is my dream for this organization?

How would things be different if my dream came true?

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.

Why?

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.

Roadmaps

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.

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.

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.