In this week's episode of Lancom TV we sit down with the Founder and CEO of DeskDirector, as well as our own Managing Director and Founder, Warwick Eade, to discuss the theory of "working backwards" and how it is used at Lancom Technology.
I chat with Warwick to discuss what is the "working backwards" approach, how we use this technique here at Lancom, and the benefits seen by customers and why we recommend that every business adopts this approach when considering a technology change.
Also, as promised, here is a list of extra resources on the working backwards process:
Read the blog article by Werner Vogels here.
Read about the working backwards process and it's relation to the Lean Start-Up method here.
Read more about the Lean Start-Up method here.
Video Transcription
Hello everyone, welcome back to another episode of "Lancom TV." I'm sitting here today with Warwick Eade, our managing director for Lancom.
Hi.
Topic #1: What is the "working backwards" theory?
Hi Warwick. Thanks for joining us. So today, we thought we would do something a little bit different than what we have been doing so far. We are going to talk to you about a process that we adopt here at Lancom, and also we try to pass on to our clients. Now, the name of this process is called "working backwards," and you may be sitting there and thinking, working backwards, what does that actually mean? Now, Warwick is an expert in not only advising us to do that all the time, but also in adopting the process. So I thought I would bring him here today to talk to you about what working backwards actually means and how that can help your business when you are looking at a project. Shall we get cracking?
Let's get going. So like all great ideas this is stone cold stolen from Amazon, who actual stone cold stole it from other people. When we say working backwards for our software projects, but all our projects, we mean working backwards from the clients, working backwards from the customer. So I read a blog post about five years ago from Werner Vogels, the CTO at Amazon about working backwards, and in that organization every single software project starts with a five-part process before they get to code.
And the first part of the process is a press release of the final software for what it's gonna look like when it's released. So they don't write any code, they write a press release on the features, the benefits, the pain points, what it can do, what it can't do, and just assuming and imagining that the software, however it's written, regardless of implementation, the software is written and this is what it will do. And it just seemed like a great idea when I saw it, and I tried to do the first time, very hard, a lot harder than you think.
I bet, because we are used to jumping into it and just getting started straightaway. Got an idea, let's do it, right?
Yeah, and we take these crazy shortcuts in our head, when the idea's in our head, then we go to a software developer, and this idea, full of shortcuts, and we go to the developer, and the developer, obviously, we're setting them up for failure. So step one of working backwards, or working backwards from the customer, write a press release on the final piece of software, what it's gonna look like. So when that's done, and this is what I read at Amazon, they don't do anything until that's done, and then in the second step they write a "frequently asked questions" list.
Wow, clever.
Topic #2: How we use this theory at Lancom
And this is where they go through all the question that a developer might ask them, that marketing might ask them. Will it be on mobile? Will it run offline? What sort of security will it have? Who are we gonna sell this to? What doesn't it do? What it might do that we're gonna avoid? What markets might we go to, what we might avoid as well? And flesh out as much Q&A as you can in your head into these frequently asked questions. So that becomes like the PR, the press release, a reference point for the developers, for the marketers, for the implementation team as they go through the project. So...
And I guess right down the track when you release it. You can always go back to that reference point that you started months ago, right?
Absolutely. The stuff doesn't get buried like most project specs. The PR release, well, you can use it as a your PR release, your press release. The FAQ, you can use it for your FAQ, and pick pieces out of that. The third phase, and this is where it gets specific to software...the first two phases, the press release, and the FAQ can be used for any project, and we're trying at Lancom, my MSP and at Desk Director, trying to get every product to use press release FAQ process. For the third part of it, the software is to get user stories and UX design. So user stories, you might have heard, is a term used a lot in software development, particularly in Agile. It's really, really simple. It sounds technical. It's not. It's just a bunch of stories saying, "As a something, I want to do something, so that I can..." And you're basically saying...
So for me, it would be as a customer experience manager for Lancom, I want to be able to please my customers by allowing them to do X, Y, Z. Just an example of what that would mean in my job, am I getting that right?
No, I'd send that back. It's much more specific than that.
I failed!
Much more specific than that. Just as an admin, I want to be able to create users so they can handle people coming and leaving from the organization.
Right, so very specific, okay.
As a person or entity interacting with the software, "I want to do something so that something..." Because if it's done well, the software developers can pick that and write software directly to those user stories, and you get exactly what you want. And they also know not to go too far and over-engineer it, and also gives them a scope to under-engineer it. But that's a little bit technical, but it's great a story, and the cool thing is a lot of user stories, like a lot of FAQs, are repeated, can be used across projects...
That's true.
...because the same questions and the same experience.
Once you do your first one, you get better at it. So press release, FAQ, user experience, and...
Lastly...this is Amazon's story...before they write any code at all, they write the manual. They actually write the manual for the software before it's written. That's a bit too for us right now, and I think we'd love to be that mature, but certainly at Lancom, we want every product to have the first two parts of the process, a press release and FAQ. And we think we're like far, far ahead of where we would be in terms of describing it, and we'll be seeing, from Lancom more and more, our customers, us asking you to write press releases. It's gonna hurt. You're gonna go, "I know press releases is easy. I'll just go knock one out."
Sit down and probably stay there for two hours, and nothing really comes out.
And then you realize that you haven't really thought it through. Or...
True.
Topic #3: Why we recommend this theory to others
And after kicking around the idea for a while, it just flows. So you'll know it's a great Litmus test for your project to say, "Have I thought it out, " and should you go ahead with it? Time to write that press release, and then the frequently asked questions. Now, we can help you with this if you're doing software development with Lancom. We'll obviously have you with the user stories to get you through. The goal being you get the software that you want at the end, at the right time, with the right features, obviously, and plan on a budget.
And for that matter, if you are looking at any other projects that doesn't necessarily need to be software developed, like Warwick stated before, try to start with a press release and FAQ, and you might find that what you have in your head doesn't quite make sense when you put it down on paper. Or it might be exactly what you've been thinking about and you just flow through the process. But the benefit, I suppose, from what I hear, Warwick can correct me if I'm wrong, is potentially cost savings because you're spending that time upfront to spec your project.
Huge savings, yes, yes.
Yeah, and a product that your customers will love because you're starting backwards from the actual development, from the actual project.
Yeah, I mean people are very experienced with these projects when they go off the rails, and half the problem with momentum of projects, if they aren't the right thing, people find it really hard to pull it back. One last bit of advice, if you're an IT professional and your customer won't do a press release, I suggest you write one for them and say...
Good one, yes.
..."Is this what we're about? Is this what we're trying to do?" And then you'll find out whether you're on the same page or not. So...
Absolutely.
...it does work both ways as well. And it's a nice lightweight, non-judgmental way of saying to your customer, "Hey, have you really thought this through? This is what I think you want. Is this what you want?" And it gives you that guiding light. It takes it away. The beauty, coming back to it, you're working backwards from the customer. We're gonna do the tech later. The technology's gonna arrive and deliver for the customer, but start with the customer, and you know, if you fix the customer and make the customer happy, everything else flows.
Will flow. Thank you so much. That's awesome. I hope you appreciated it. There will be some comments down here, which you can follow through to read more about the working backwards process, and we'll be back again next week. Thanks, Warwick.
I hope it helps.
See ya.