How To Frame the Decision

When starting the process of laying out a plan to build a great product you must start by framing the decision. Great tips from Marty Cagan’s Inspired: How To Create Products Customers Love.

  • What problem exactly are you trying to solve?
  • Who exactly are you trying to solve this problem for (which persona)?
  • What are the goals you are trying to satisfy with this product?
  • What is the relative priority of each goal?

Here’s how I laid this out on the wall of a recent project. It’s pasted just before the initial wireframes.

Frame the Decision

Broken Windows Theory


This theory, most famously put into action by New York City mayor Rudy Giuliani, helped lower crime rates city-wide over a short period of time. Removing graffiti and cleaning up the city lead to lower crime and murder rates.

Monitoring and maintaining urban environments in a well-ordered condition may prevent further vandalism as well as an escalation into more serious crime.

It’s the small attention to details that matter most. Technical debt and shortcuts in your software and are contagious. By themselves they can easily be overlooked, but piled together it’s no longer fun to work in that codebase.

Just as graffiti makes a neighborhood rundown, so too does messy code affect an application. Pay attention to the small things and don’t release junk. Take a stand in your part of the application and the rest will follow.

How to be Perceived as Being Credible

In The First 90 Days, Michael Watkins writes about new leaders making transitions. He says they’re perceived as more credible when they display these characteristics:

  • Demanding but able to be satisfied
  • Accessible but not too familiar
  • Decisive but judicious
  • Focused but flexible
  • Active without causing commotion
  • Willing to make tough calls but humane

Since perceptions are weighted so heavily in people’s minds it’s important to make a good one in a new job or new role. Make this your priority in every initial transition.

Release Early and Often

Tempting as it may be to sit on your new code, working to improve and make it the best it can be, it’s the wrong thing to do.

We’ve all been there: the new project is cool; it looks great and customers will love it, but it’s not quite ready. Just a few more things to make it look really great.

If you’ve ever had to decide the best time to start having kids you already know there’s never a great time. You’re never fully prepared, your finances aren’t in order, but you do it anyway.

Cod is the same way. Release your Minimum Viable Product as quickly as possible and schedule time to iterate as quickly as possible. The added benefit is a shortening of the feedback loop. You might decide not to spend days building and perfecting something you thought would be great when users tell you they don’t actually want it.

Release your code early and often. You’ll never feel ready but that’s the point.