Customer-First Development

Some things I’ve come across the last few weeks got me thinking.

First, an excellent blog post by Gojko Adzic, Writing “As a User” does not make it a user story

This post reminds us that too often our user stories are lies. We write stories that misrepresent what the user really wants to do and our stories are biased toward our implementation preferences right from the start. We’re polluting our solution before it even has a chance.

We should be brutally honest about what the user really wants to do and then focus on that first. User first.

Second,  I recently re-watched this old video of Steve Jobs while I was killing some time

He responds to a tough, condescending question with an epic response. Most of what he said was about what Apple was trying to do at the time, but there was something he said that hit me because it’s describes something that we’re constantly failing to do well in our industry:

One of the things that I've always found is that... you've got to start with the customer experience and work backwards to the technology. You can't start with the technology and try to figure out where you're [going to] try to sell it. And I've made this mistake probably more than anyone else in this room and I've got the scar tissue to prove it. And I know that it's the case. And as we have tried to come up with a strategy and a vision for Apple, it started with "what incredible benefits can we give to the customer?". "Where can we take the customer?", not starting with, "let's sit down with the engineers and figure out what awesome technology we have and how we're going to market that". And I think that's the right path to take.

That was in 1997.

But it’s 2013, so why are we still delivering things that people don’t like to use?

You mean this thing that I spent the last year building isn’t exactly what you wanted?…

Projects are still water-failing, but we’re supposed to be past that aren’t we? But communication is hard. We’d rather not think about that for a while and go play with our favourite language. We’re pretty clever… we’ll build the fanciest thing ever. We’ll use TDD, we’ll have some sweet RESTful services and the cleanest API you’ve ever seen. And we’ll even continuously deliver!

Not that those things are bad. They’re pretty awesome. But let’s at least make sure we’re building the right thing before we continuously deliver something no one really wants.

We still seem to place too much importance on our favourite frameworks, our favourite tools, our development methodologies. We easily get bound to a stack or jump into dependencies on third-party tools before we’ve even considered whether or not we are building the right thing.

Which reminds me of something else.

I really hate seeing projects become too dependent on third-party tools to the point that it becomes difficult to just say yes we can build that. Oh, there’s not a component for that… sorry, we can’t build that. Oh.. I guess we’ll have to tell the users that it’s not possible.

Are we afraid to invent, create our tools, make hard choices, and solve real problems? Are we afraid that when we try to solve real problems, we might need to get dirty?

Developers that have the ability and mindset to build whatever is necessary to create the best possible solution to a genuine need are rare.

We have to break out of the mindset that our tools and languages are limiting what we can achieve. We’re the ones limiting what we can achieve when we say things like “sorry, that’s not possible in [some framework]”. If your tools limit you in any way, maybe it’s time to switch.

Our goal is never to “build a website in [insert technology here]” or “create a mobile app”, but should be to solve a real problem.

Hi. I'm  Mark Thiessen. I love technology, jiu-jitsu, and coffee. My opinions change over time.
I'm passionate about working with teams to learn to continuously deliver software and help ensure the valuable things are delivered incrementally and measured and improved.