Humans are bad in imagining the impact of things. What we are good at is looking at and touching things and then understand them. It’s how we became who we are. We created tools not by thinking of them. We created them by needing them, working on them as things, trying them and then improving them. The work we do in our domain is much more abstract and complex. Yet we take little time to understand our products and their impact better by treating them like things. Many other professions do that: Designers, painters, builders, gardeners, the nice people at Pixar. here a few ideas how we can treat our products more like things.
I Am The Worst. The Video.
My wife is editing movies and TV series. A couple of weeks or months ago, I wanted to edit a very short video. I imagined how it would look like. It was a really simple setting. I desperately wanted it to be something. So I gave it some thought and imagined it soothing from calm. The conclusion was to give it some fade-to-black edits to make it calm. Being new in the video editing business, I asked my wife for some validation and acknowledgement. “I want it to be real calm, so I though about doing some fade-to-black edits“. “Great, I think you can do that.“, she said. Fine!
Restless, a night later, I thought about the video again. Now I wanted to speed things up. Calm was yesterday. More direct cuts was the conclusion. So I asked my wife. She said: “Sure: Give it a try!“ Then again, just a few days later, I though about some music. You get it: I asked my wife. This time the answer was different. What she said was: “I think you can try all of this. You have to see it. Did you actually try any of this and do it?“ Aaargh. There she had me. Of course I didn‘t do any of this. All I did was dreaming, thinking, wishing for something. And of course I couldn‘t really imagine any of the options. The impact they would have. Editors know this. You have to see it to know what it does to people. If it works. I felt so erwischt.
It was humiliating. Me! Me, that I am preaching to treat digital products like things. Because: We can‘t imagine what the changes the add ones to our products really do to people. If they work., Or if they are just fancy ideas. Until we see it, most of what we are doing, thinking and planning, is just an idea, often expressed in a Jira ticket, making a whooshing sound, being pushed from the left to the right. “Done“. The more complex the product, the more complex the org we live in, the more tickets make it from left to right. Done. But what do they mean? What do they do together? Do they work?
Often, I am full of envy of people working in hardware. Any hardware. I read the book by Ken Kocienda, how at Apple they always worked at and with the thing and always knew about the effects their work had (or didn‘t yet have). I am full of envy of my wife, realizing turnarounds of a few minutes or hours with colleagues on the effect a certain edit or ways of editing have. Or on the structure of a season, or episode. I am full of envy of the people sitting at Porsche working on door handles and together judging if they are Porschey (if this ain’t a word, I herewith make it one!) enough or if last week was a waste of time and they need to make it more Porschey again. I know it‘s more complicated than this. But at the core, they work with the concrete thing and they kind of know what out does and they decide by using the thing.
Norbert Haller, a friend of mine, designing eBikes since 20 years. I am so full of envy on the work on physical objects and feedback on physical tings. Here you can listen to him talk about his work in my podcast (German only) with him.
From experience, I know that working with our SW as it would be thing and looking at it and using it, makes all the difference. I know it, because when I was starting my career as a SW dev, it‘s what we did. We worked for some time and then demoed to each other. Read Ken Kocienda’s book! Of course, we were not as brilliant. But we always knew what worked and what didn‘t and had a good grasp of the user. We continuously used the SW we were building. And boy, was the SW ugly. We clumsily used Self-HTML, which which will have its 25th birthday next year. But it was our only chance to have impact in the web. The designers wouldn‘t talk to us at the time. They had much higher rates than we had. If they talked to us, we wouldn‘t understand the words they though at us. They didn‘t have a seat at the table at the time because they didn’t want to. Anyways.
Other Professions Do It All The Time!
Here is my point: There are so many professions just knowing you need to have the thing in front of you to discuss, to decide, to argue, to fight, to get to grips on what all of this means and does. Designers do it, movie editors do it, Pixar does it all the time, musicians do it, … But somehow we in software think, we can figure out what these 50 Jira tickets do when someone pushes them in “done” and hits “release”. We can‘t. It‘s funny. We say that our work is so complex that it‘s hard to forecast and at the same time we leave it in the abstract, rather to make it more concrete.
So here are a few ideas on what you can do to treat our products more like things and thus better be able able to understand, discuss, argue fight and come up with a better product.
Here some suggestions on ways get closer to treating our products as things.
Do a real sprint review
The sprint review is actually meant to treat our product like a thing. It‘s not meant as an acceptance meeting. It‘s meant to get feedback. We through our product out in the world and watch what happens. The main point is having the product demoed just like a thing. Demoed, used, reviewed and feedbacked.
Have a Weekly Product Review
The one thing I like to get Product Owners and Product Managers do is to each week sit together, use the product. Explain the changes they intend to do, that were done. use it, get feedback. Think what should now be done. For some reason it is hard to get POs and Product Managers to do this. We seem to be kind of lonely wolves, heroes at what we do. I often see product meetings without the product being visible at all. Give it a try! The level of concrete insight and decision is mind boggling to me. The best things in life are free.
Regular User Tests
The point is regular. Not most fancy. No matter how small. User tests not only give you feedback. They also force you to present your product as a thing regularly and get concrete insight again. But now from people living in a different universe. Even better than feedback from peers. But don‘t count off peers. They are brilliant for feedback. They appreciate the complexity of you problem from a relatively neutral stance and have an outside view. Friends are too benign, the boss is too conservative.
Casually Show It To Colleagues
Linger around a coffee machine and show your latest idea or iteration to some colleagues. From finance, marketing, whatever. Change coffee machines to get more diverse feedback. Believe me, any feedback will do!
Always Have It Running On a Tablet Somewhere
Have spaces around your office where a tablet is mounted, running your latest release or experimental release and observe people. Let them write down comments. Your devs will love keeping this thing up. Constant feedback also gives you agency: What is the impact of my work?
Regular Team Demo
Start your sprint preparation or whatever prep meeting you are having with a team demo. What did we do? What can we see? Does it work? Was it a good idea?
Show It To Your Partner
It was always hard for me to explain to “normal people” what I was doing at work. Also at home. It was just too abstract. All my wife could remember was when I had to travel to Kiev or some other place. But after showing my product to her regularly, that changed. And, honestly some of the valuable feedback came from my wife. She recognized some of the biggest issues upfront, because: outside view.
Have a Screenshot As A Top Jira Field
If you have to use Jira, make something of it. Make it more fancy. Give your Jira some product flavor and make one of the top fields a screenshot, a drawing or anything that communicates what this is all about. It’s makes all the difference.
Screenshots, Images All Over The Place
Just like in Jira, put screenshots, images, drawings on the walls of your team space. Put them on the tickets on your analog team board. If you are working on a flow, put it up on the wall. what works, what doesn‘t? Where was the drawing a good idea, but real life sucks?
Have The Product Always Running In Your Team Space
Just like the table in your company, have the product always running in your team space. Once a discussion on a minuscule issue starts, go to the product and discuss based on the product.
These are just suggestions. Give them a try. Tell me if something worked for you. Try something else. Whatever makes your product more of a thing to you, will make all of a difference.
How do you do it?
What other ways have you found to be helpful in making your product more thingy and less abstract? I‘m listening! Do you also envy the hardware guys? Or is it just me?