Your favorite song comes on the radio while you’re driving. You know the one. The one single song in all of music that makes everything seem ok. You reach down and crank it up. And to your surprise, your transmission is 200 feet behind you. This is one example of the Frustration & Astonishment Factor. Actions we take every day that, in one, and only one example, create untold destruction.
Someone on the assembly line probably thought “I’m NEVER buying this car.” A car buyer probably doesn’t look at how this is setup until they go to turn up the volume. And then they’re pissed.
We do this in software all the time. We put up response boxes that say “Do you want to cancel?” and render CANCEL and OK buttons. We put important actions and statuses in areas that are not in the user’s view. And then we tell them “you need to learn how to use the application.” No, we need to build the application in a way that mimics how people think and work.
But I see examples all the time of a button on the left collapsing an accordion on the right. Stop doing that. You’ve increased the Frustration & Astonishment Factor. If all the text off all the buttons on a page, your users should still have a reasonable idea of what button probably does what action.
I don’t know where the conversation is going when I speak with stakeholders. I have a general feel but their responses could take us in an entirely new direction that we never thought to explore. I usually start with “what drives your business” or “what makes people want to buy from you more than once” and go from there. It’s usually followed up with “how do you know you’re getting more or less successful” or “point to what you’ve given up on”. If you get past the “it’s fine” you’ll find that there is a never-ending stream of things to improve on.
Face to Face With the Customer. You can send out as many surveys as you want but you’ll never understand the aggravation your user community is feeling until you’re sitting across from them while they struggle to use your software.
Let’s start off with what an MVP is not – it’s not the least amount of stuff that can be done in the 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 anything, then you’re not really building an MVP.
When I talk to Scrum Masters, 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.
There are two forces at work when developing a product. 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 run late. Sometimes over budget. But they usually asked the right questions of the right people. They also observed the setting and how the product was being used. They knew when people asked “WTF?” and when they said “I love this!”. And more and more people start using it.
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.
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.
Because they really mean the same thing. As a Product Owner we’re supposed to surprise our users when we can. When we cant surprise them, at least we shouldn’t bore them. When I’m getting feedback from the team or from the user community, if they’re about to say “it’s ok” then just say “it’s shit” and let’s make it better.
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.
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.