Common ground question

Process & Techniques
#1

I have a developer on the team who is trying to start his own business. As a result, he spends a good amount of time with the app he’s developing. He is a student of “lean startup” and is now opening trying to advise that we no longer use UX and prototyping (I use paper/Balsamiq/Axure RP) but rather start directly developing the apps for feedback. I’ve tried to explain the differences between a lean startup environment and one such as our (Department of Defense) but he doesn’t want to budge.

Any ideas on how I can help him understand how critical UX and prototyping can be to the success of a project?

#2

Johnathan Swift’s quip that “Reasoning will never make a Man correct an ill Opinion, which by Reasoning he never acquired” applies perfectly here. You’re unlikely to be able to make any argument to him that will show that he is wrong, and trying to do so might be banging your head against the wall.

Is he the one with the power to implement that decision? If not, your best bet will be to head him off at the pass and get in the ear of the person who does have that power before he does.

It’s an unfortunately but real truth that we often have to play politics in our jobs. This appears to be one of those times when you’re forced into that realm.

1 Like
#3

Agreed. I think you’re right. Still, I’d like to be able to find some kind of common ground with him. I’ve studied lean start up, and some of the core principles are there. Both recognize the value in testing, early and often. Gathering data plays a critical role. I even tried to give him copies of a few books (Think First, Rocket Surgery…) but he wasn’t interested.

Maybe the best thing I can do is educate myself on the methodology and make sure I’m prepared well when it’s brought up in conversation.

Thanks for the advice!

#4

UGH, I hear your frustration. While I get Doug’s point about politics, I think there are some pieces of information that could help you.

One of the worst misuses of the Lean Startup concepts is skipping straight to building something in code. I think the catchphrase of the Build, Measure, Learn loop throws people off, because they think they need to begin with building something. In reality, Eric Ries actually suggests starting with a period of getting out of the building to talk to people and confirming that they have a “significant problem worth solving” (which is UX research…that quote is from page 88 of Lean Startup - Show your colleague!) It’s after this first step that you’re supposed to leap into the Build, Measure, Learn loop, and even still, the goal is to get through the entire cycle of learning as fast as possible, not just building something as fast as possible. This is a big semantic, but the focus on working code is a tenet of the Agile development process, which isn’t actually the same thing as Lean Startup.

To get back to the Lean Startup feedback loop, you’re supposed to begin by building an MVP (minimum viable product), which is whatever you can build with the least amount of effort that allows you to test the the hypothesis, which means it could be anything from a landing page to wireframe to a sketch, as long as you can test your hypothesis out and decide whether to keep on the same path or pivot to a new solution. With this lens, you can argue that you save time when you learn by testing (and possibly pivoting away from) a wireframe rather than a working piece of code. The whole point is to get through the entire learning cycle as fast as possible.

For more reading on this, checkout https://www.agilealliance.org/build-measure-learn-lean-startup/

3 Likes
#5

Also maybe helpful - https://library.gv.com/shortening-the-build-measure-learn-cycle-with-clickable-mockups-c588b173bdf7#.ji3ij2qkr or https://www.cleverism.com/how-build-measure-learn-cycle-really-works/

1 Like