Customer-First Development

Some things that I’ve come across in the last few weeks have 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:  Steve Jobs Insult Response

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 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.”

Oh snap. Customer experience first – in 1997. But it’s 2013, so why are we still delivering things that people don’t like to use? Projects are still water-failing, but we’re supposed to be past that aren’t we? Communication is hard. Responsibility is hard. We’d rather not think about that for a while and go play with our favorite language. We’re pretty clever… we’ll build the most awesomest 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 favorite frameworks, our favorite 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?

I do think that there is generally a lack of developers that have the ability and mindset to build whatever is necessary to create the best possible solution to a genuine need. 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. After all, you can build anything can’t you? And if cranking out something yourself is truly the best way to solve the problem, maybe you should – I don’t know.

I do know that we should at least be staying focused on building the right thing all the time, continually keeping our goals aligned with building what the user really wants. 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. So go out there and make users happy. Question everything. Even requirements! Especially requirements. Communicate more. Demo more. Build cool stuff. Throw out stuff that sucks. Get real feedback from real users. Iterate towards perfection. It’s worth a shot.


Originally posted by Mark Thiessen at Mutable Thought