Tribal Workarounds

0

In the absence of knowledge comes ‘this is how I got it to work.” People and groups will fill in gaps in knowledge. If you either don’t train people, or your product leaves areas of ambiguity, then people will take the easiest path forward – they’ll either give up, or, they’ll find a workaround that gets them what they need. And one day you’ll find these and be completely baffled as to how they came into existence.

Sit with your teams, see what they do, better yet, do it yourself. I’ve done this with every team I’ve worked with for products and I’ve found that issues going back to a customer for resolution had actually already been solved. But the solution was buried deep in a menu structure that had been forgotten about over time.  If your teams are customer facing, sit with them for a day, see what you learn.

Build a Product That Fixes Your Customer’s Problems, Not Your Own Problems

0

Over a year in development. Marketing staff to create content for promotion. A development team ready to fix bugs and add functionality. Lengthy arguments as to whether or not the background should be sea foam green or something else.

Total number of users: 0. After 2 years.

The platform was built to facilitate order entry because it was a lengthy process for us to complete it. So we pushed the work onto the customer and said “you’ll love this”.  Well, they didn’t love it because they didn’t care. It wasn’t their problem and it was an obvious ploy to push work on to them. The platform existed for more than two years before it was finally shut down.

Ask yourself this when building a platform or product: “Why would a customer use this?” If the answer sounds anything like “because we want them to” then you should probably not spend much more effort on it. If you need evidence, create an email campaign that points to a landing page asking people to sign up and they’ll be notified for a beta. It should tell you a lot if nobody signs up, even more if nobody clicks.

0

I’ve been re-reading Adam Grant’s book, Originals for the third time and this time, focusing on increasing output and not increasing quality. Sounds backwards doesn’t it? Most people I’ve worked with in the past want to create brilliant work but what Adam points out is, even geniuses like da Vinci had higher incidences of “brilliant work” because they were prolific creators. The more you create, the higher the chance that your output creates brilliant work.

Many individuals I’ve worked with in the past want to create work that impresses. They spend so much time on trying to get it perfect that they actually produce anything.

If you haven’t yet read Originals yet then please get a copy. There are several other observations within it that can lead to some tremendous breakthroughs.

The Cost Will Reveal Itself Once the Complexity is Understood

0

My wife texted me the other day and asked me a question about whether a project for the home was expensive or complex? My response was an off handed comment that “The cost will reveal itself once the complexity is understood.” Since you don’t know everything up front, you can’t possibly say how much a project is going to cost unless you’ve done the exact same project previously.

A players think they’re B players.

0

A players think they’re B players. B players think they’re C players. C players think they’re A players.

I forgot who said this but it wasn’t me.

A players know they have a lot left to learn. B players know they have a long way to go. C players don’t realize how high the mountain is and think they’re at, or near, the top. A players drive discussion and inquisitiveness. The constantly question whether or not they’re right. Many (usually C players) confuse these two attributes with not having any answers and lacking self-confidence. Completely wrong and further underscores how much the C players have to learn.

Engineering-glish

0

Engineering-glish:  The act of speaking to end-users as if they were engineers.

I have a new analogy that I’m using with software engineers. Every time I hear “why would someone do that?” or “They should know not to do that…” my response is now, “How many of you drive over a bridge on your commute?” Since we’re in Florida the response rate is about 99%. “Somewhere there is a bridge engineer asking why any of you would drive over a bridge like you are.” I usually get a “WTF are you talking about?” look or response. The software engineers are pretty confused and I respond with “That’s the same look our end-users give us when we speak to them like that. Somewhere there’s a bridge engineer asking why there would be so many stationary, overloaded trucks on the bridge, and why someone would be so close to them, the bridge wasn’t designed with that in mind.” There are thousands of calculations dealing with compression, harmonics, wind, temperature, etc., do you as software engineers truly understand the bridge you’re driving on or do you just want to “use it” to get where you’re going? It’s the latter, get where you’re going. That’s the same for end-users – they don’t want to, nor should they have to, consider how the software was built in order to use it. SPAs are a prime example of this. Hitting the back button wipes a large portion of your selections yet it’s not obvious that a site is build as a single page. Software engineers ask “why would anyone do that” and end-users ask “why would anyone build it that way”. It happens all the time where software engineers are trying to explain to end-users why they shouldn’t hit the back button and it’s a prime example of engineering-glish.

A personal note about hydrocephalus, especially in children.

0

Hydrocephalus affects more than 1 million people in the US each year.
Costs related to treating hydrocephalus exceed $2 billion each year.
Amount of money spent on research annually: $8 million.

We’re raising money again this year in the hopes of finding a cure, not for our son, but for all the others who get diagnosed each year.

In 2017 our son was diagnosed with severe hydrocephalus. You know you’re in deep shit when your son went in for an MRI and the head of pediatric neurosurgery takes you to a small room to explain the situation: a large mass of fluid in the middle of your son’s head. And he’s barely 8 months old. He was taken to surgery the next morning to implant a small catheter into his brain.

Almost two years later and he’s progressing faster than expected, even after two additional brain surgeries. He’s doing great with physical therapy and you’d never be able to tell what he’s been through by looking at him. He just can’t play football. And no boxing. Other than that he should grow up as any normal kid would.

Until this happened, my wife and I had no idea what hydrocephalus was, nor how common it was. We did not understand how lethal it used to be in the US and still can be in remote parts of the world. We have my son taken care of, but help me and many others end this so no other infant has to go through what my son has gone through.  Donate to the Hydrocephalus Association where my wife and I will be walking to raise money for research.

Hydrocephalus Association is a qualified 501(c)(3).

The Frustration & Astonishment Factor.

0

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.

As a Product Owner, I don’t know what questions to ask.

0

I don’t know exactly 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. From that list you’ll begin to put together a list of backlog items.