Let's connect

twitter|@phmarco  •  facebook|marco.moreira

linkedin|link2marco  •  skype|phone4marco


123 Street Avenue, City Town, 99999

(123) 555-6789



You can set your address, phone number, email and site description in the settings tab.
Link to read me page with more information.

How to build something people want: the start


How to build something people want: the start

Marco Moreira

These are some lessons learned from this weekend’s hackathon at the Microsoft NERD. Cheers @andresdouglas, @disasteraccount, sethish.com, github.com/topher200!

There are times in life when a web person gets to build a product from scratch based purely on an idea or problem to be solved. No pre-existing code, no tech constraints, just sheer possibilities ahead. Exciting right? That’s until our ADD minds get in the way. Usually, the process goes from something like “Omg this is the greatest app the world will ever see” through 43 iterations of “wouldn’t it be great if we added _______ to it?” and finally ending in something that does a lot of half-assed things that don’t make anybody happy, if it gets deployed at all.

A typical software project

A typical software project

Why do we do this? Beginners and seasoned people alike tend to put themselves through this same loop of excitement > build, build, build > sucky end product/abandoned project. There are many reasons, but let’s talk about 2 early factors that are easy to spot and solve so that you can start building something people want.



We’re in the 3rd paragraph of this post and I have a question for you: how many times did you wander away to check your phone, twitter, facebook, etc. already? There you go, nobody can focus anymore now-a-days, myself included. This truth is likely to be the biggest drain on your motivation to complete anything, especially a piece of software, which our brains haven’t really evolved to think about in the first place.

So here’s a quick fix that works wonders for me: When starting a project, you need to have someone other than yourself who can be the “product owner” (PO), or the person who can tell you what matters and what doesn’t. If you’re trying to solve a problem for someone, that person already exists. The product owner will be the source of a golden idea: prioritization. That means you’re not in charge of what gets built, the PO is. There, you just saved yourself the agony of deciding what to do next. And as the scripture says, “prioritization shall lead you to the focused path”. Or something like that…

Now here’s a likely conversation: You will ask the PO what the problems are, he/she will give you a laundry list. You will propose solutions, he/she will agree to 80% of what you propose (why? because who would say no to having their problems solved?!). Now you have a laundry list with 39 things the software “must” do. Marco, WTF just happened?! Well, your next question should be “if I can deliver to you ONE thing out of this list in the next X hours/days, what would you rather have?” Oh, the wonderful threat of scarcity will get your PO to finally give you the priority and focus you seek. All of the sudden Flash-based tag-clouds of potential meta data items become irrelevant. I doubt you will really walk out of the conversation with just one requirement, but at least it won’t be double digits, and it sure as hell shouldn’t be more than 3 or 4.


So you have the 2 or 3 things that your v0.1 must do. Surely, the best thing now is to lock ourselves into a room free of distractions and build the 8th wonder of the world expressed in software form, right? No, because of a simple fact: you’re wrong. In fact, you (and I, and everyone who builds software) will be wrong many times before they are marginally right. In my opinion, makers of software tend to be most wrong when it comes to UI/UX development, because, well, that requires asking people who are not even close to being as intimate with the project as you are (ie. your users/customers) to comprehend the marvel you just produced in the attention span they tend to have: 3-5 seconds per page.

The fix: get something “real” up and going now. A paper prototype, a Balsamiq wireframe, a barebones html page, it doesn’t matter. The goal is to quickly (as in minutes, not hours) and iteratively start weeding out the assumptions you made on your UI because that’s the way you use a computer. Needless to say, this will be a humbling exercise, but it will do 2 very valuable things: it will increase your PO’s respect for your work, and everyone now has an common vocabulary/visual reference to reason (ie. argue, fight, bitch) about.

The number of times I was wrong in the span of 2 hours. How are your assumptions doing?


All of this is great, but the only objective measurement of progress should be aworking product at the end of the time you promised your PO way back when you first talked. The term “working product” should be explained as “functional, or doing the 2 or 3 things we agreed on back then”. That means deployed, operational and ready for real-world battle. It does not mean pretty, ajaxy, optimized for SEO, etc… If you can get those worked out in time, more power to you, but the primary goal is to solve the problem(s) agreed on in the first discussion.

Alas, a finished, half-polished, but WORKING product. Get to this point, I beg you!

It is almost an automatic thing that we then turn on to the next discussion of “must” have features the moment the app is live. I would suggest to you a couple of thoughts: 1) let people use it for a while without “improving” it; only fix absolutely show-stopping bugs; auto-complete search boxes can wait. This will teach you about the real pain that still lingers in the next chat with the PO and will make this process easier on your souls. 2) For the love of God, enjoy your finished product! Hopefully your PO is sobered by the amount of work it takes to produce a limited solution, but it’s still a solution! Bask in their excitement about the future and stories of how “my life is now so much easier!”

Good luck makers, the world awaits your rescue!