F2FWTC™

, 0

Face to Face With the Customer. You can send out as many surveys or do as many focus groups as you want, but you’ll never understand the aggravation your user community is feeling until you’re sitting next to them while they struggle to use your software.

Sit with them. Don’t explain how to use the software. Watch them struggle. You’ll learn more in an hour by watching them then you will in days of focus groups and hundreds of surveys sent out.

I was fortunate enough to see Steve Blank speak once at a Tech Stars Founder’s Conference. He made a very clear point: the answers are not in the office, get out of the office. Go talk to customers. That’s where the answers are.

 

What an MVP is, and is not.

0

Let’s start off with what a Minimally Viable Product (MVP) is not – it’s not the least amount of stuff that can be done in a sprint. What it is intended to be is a learning tool, you’re supposed to be validating your hypothesis (or hypotheses) with an MVP. If you’re not validating something then you’re not really building an MVP.

When I talk to Scrum Masters, development teams, other Product Owners, they seem to be confusing the intent of Build-Measure-Learn with The-Least-Amount-We-Can-Do-And-Still-Be-Considered-Successful, or TLAWCDASBCS. The TLAWCDASBCS is a function of team availability, capital, time, and volition. It’s the minimal amount of stuff you can do to get people off your back and appear to be making progress.

If you’ve reached product-market fit and you need to refine features further, you can then drop one level down conceptually to a Minimally Viable Feature (MVF) to learn more from customers about what the features truly need to do for them.

 

Agents of the Epiphany

0

There are at least two forces in product management: Agents of Chaos and Agents of the Epiphany. Agents of Chaos state emphatically what needs to be built for customers, without ever speaking to a customer. Agents of the Epiphany don’t know exactly what needs to be built but routinely watch and speak with customers.

In the end, products run by Agents of Chaos end up not being used and no one can understand why. The features where built. A profitable price point was set. The product was marketed. It was delivered on time and on budget. But it’s just a junk pile.

Products run by Agents of the Epiphany sometimes run late, are sometimes over budget, but they always come up with answers that are unpopular within the company. However, customers and clients do understand the answers because the product teams usually asked the right questions of the right people. They also observed the setting and how the product was being used. They saw when people asked “WTF?” and worked to turn it into “I love this!”. And more and more people start using it as a result.

The only two things that really matter are whether or not people are using your stuff and whether or not you can get them to pay money for it. Make sure you’re listening to the right people who can get you there.

 

Set the course so the team can make great decisions.

0

When working with a new team or facing a new problem, I never say how it needs to be done. Rather, I form one

question that the team needs to focus on. Answering this question helps the team keep focus on what’s truly important.

For example, working with a development team that is now dealing with a significant increase of customer complaints. First, do your homework. What are the complaints, is there a trend, is there one set of users that is experiencing the problem, just a basic understanding of the situation. Then you need to set some guidelines for the team. “If we were going to solve this…”

When the team starts to go off track, get them to re-focus on answering the question. They can refine the question, improve on it, but not ignore it or set it aside.

I’ve rarely seen this fail, and when it has, I forgot to keep the team focused. Any team can usually come up with a better solution than any single person can, you just have to figure out how to get them to collaborate. Forming a great question, one that defines the boundaries, usually gets unexpected, and outstanding, results.

 

Some of the best product advice I ever got.

0

I was fortunate to listen first-hand to Steve Blank explain, in no uncertain terms, that if he ever found his Marketing team in the office again, he’d fire them. Because the answers aren’t in the office, they’re “out there”. So go “out there” and find the answers.

So many times I see people guessing at the answer as to why their product or feature isn’t being used. It’s ridiculous. Go talk to your user community, face-to-face. Watch how they use the product, watch if they use the product. If you’ve done any homework at all you’re usually just a few small tweaks from the feature being really useful. If you’ve just guessed at what feature your user community needs, well, then you’ve got a much bigger problem. You’re probably screwed to start with.

Know the difference between kicking the ball around and scoring a goal.

0

In one of the recent podcasts I listen to the statement was made “…people just don’t know how to think…” and I’ve been struggling with identifying this for a while. One company I worked for, you could just see the decline in YoY profitability, yet they were on-boarding people (because the solution didn’t scale but that’s another post) at a tremendous rate. I characterized them as having a triangle shaped hierarchy – a lot of people in management positions but relatively few doing actual work. At some point there would be just one poor schmuck at the bottom doing everything. You could see it, it was obvious, yet behaviors didn’t change. They literally looked like a bunch of 5 year old kids kicking the ball around on a soccer field. After unsuccessfully trying to point this out for a year, I decided to get the hell out. From the same podcast “..my dog is a genius [compared to these people], he knows what he needs and goes and gets it…”  I’m baffled why people don’t understand what makes it profitable, and focus maniacally on those few things.

The Real Role of the Product Owner

0

Here it is: provide clarity where there may not be any, and enable the team to consistently and predictably deliver value to the company.

Some may describe this as the intersection of UI/UX, Business, and Tech. Others may describe this as building the right feature at the right time. It is without a doubt, a strategic business role that requires both long and short term perspectives.

How do you measure the success of a Product Owner? As Josh Elman has stated, “The only metric that matters is, are people using your stuff?”

That’s it, keep it simple.  If you can’t keep things simple, you can’t execute consistently.

 

From Concept to Launch, Own the Results.

0

One of the best lessons of product ownership I ever got was from a CEO who asked me “How did this get away from you?” My response was “Well, Marketing took it over…” He lost his shit over that response, and rightly so. The initial intent of the product got away from me and got watered down. What launched publicly was embarrassing and had almost nothing to do with the original intent that I had identified. When you bring people on to help with a product (and you’ll have to, you’re not omniscient) they should elevate the product. Add to it, improve it, make it better and make it something that everyone is proud of. If it goes to a committee, I guarantee you it’s going to turn into a piece of shit. You need one person that’s responsible for making sure it meets or exceeds the original vision of the product.

Product: It’s difficult and time consuming.

0

Building a solid product, or even building a solid product team, takes time. If you’re responsible for a product and you don’t understand this, it’s going to be a difficult time for both you and the team.

Here’s an analogy. Races aren’t won on race day. They’re won or lost on all the days leading up to it. Race day is where you show how hard you’ve worked on all the little, seemingly inconsequential tasks. I’ve seen some people show up on race day and think they can just push themselves harder than anybody else. But their lack of dedication and commitment shows quickly and they get left behind. You’ll usually hear these people say “we didn’t work hard enough in the race” completely missing the point that excellence is a day-to-day habit. It’s incremental. It’s trying to get .5% better every day, and even that is exceedingly difficult to do. A tiny improvement every day completely changes the end results you’re able to achieve, and, in my opinion, they stick with the team over time. It’s the same with a product and the team building it. Tiny changes make a big difference in the long run.