Back when Expected Behavior was a consulting company, one of our biggest competitive advantages was providing our final estimate during the first meeting. Once we handed out that estimate, we never asked for more money unless the client asked for something substantially different (e.g. "I know I said I wanted a rocket ship, but now I want an apple orchard").
There were 3 key things that made it possible to provide a rapid, accurate, profitable final estimate that maintained good work-life balance (no crunch time for us).
- Burndown maintained an accurate, easy-to-use schedule across many teams and projects. Accurate project management through Burndown was critical for delivering on time without anyone at EB working outside their normal hours.
- Product sketches for creating a meeting of the minds between us and the client about what they wanted to make. This post is about the sketching process.
- Our Secret Sauce Estimation Formula which took the sketches as input and produced amazingly accurate estimates. The formula was developed using data accumulated and analyzed in Burndown.
We're a full time product company now, but we used the sketching process to get started with building Burndown and it was still as helpful as always.
What's a product sketch?
A product sketch is a poorly drawn representation of the ideas that should be in the product. When I say poorly drawn, I mean it. I have absolutely no drawing capability. If you can draw anything that resembles a box and anything that resembles a line, you're good enough. The goal is to represent all of the important ideas without caring much about how they'll be actually look when the product is designed. Even the actual working of a thing can be pretty vague. Maybe you know that the user will need to sort an object, but you don't know how exactly. You're covered as long as something appears in the sketches that clearly indicates "user sorts objects" to you.
Are poorly drawn lines really going to help me?
Pictures are the easiest way for a group of people to communicate about what they want to make. It's surprisingly important to have the sketches be poor quality. In the beginning, nobody has a good idea of what they want to make. Quick, low-quality drawings are a good way to meet the psychological needs of focusing on what you're trying to achieve without getting deeply drawn into more complicated questions like "how?". As the quality of the sketches increases, the pictures start to convey permanence or at least strong relevance to the final design. That turns your sketch meeting into a design meeting, which is not what you want. It's not worth deciding on the design of anything before you know if you've got a whole, coherent idea.
Also, Poorly Drawn Lines is a great comic.
How does it work?
Three or four people sit down in a room with some printer paper and markers. Ideally, the people have some variety in their expertise. The Burndown sketch team included me, Tony, and James, so we covered product management, business, development, and design. I don't recommend more than four people for this step. If you want more people to be involved, consider making that happen in the next step.
To start, choose an obvious entrance point to the software. We chose the log in page.
There's not really anything exciting about this picture. It's a very ugly version of a page you've seen thousands of times. Even the obvious pages should be included in your sketches.
The only thing to do on this page is put in your login info and click the log in button, but "clicking" is where the magic happens. When you "click" a button, you need to hold up the piece of paper that shows what you'd see next. If you haven't drawn that page yet, now's the time. For Burndown, that meant drawing the Projects Overview page.
Now we're onto something more interesting. This sketch might not make complete sense to you (because you weren't there for the sketching), but it's a clear step into the meat of the application. It's got a bunch poorly drawn lines, a project listing, some possible notifications, and it links to a bunch of other places in the application (Archive, Edit, Audit History, etc). Not only are the lines poorly drawn, but many of them are crossed out. That happens, especially to an important page drawn early in the process. For example, we started off thinking we'd notify you when tasks needed your attention. Later, we realized that simple notification would require all users to oauth with external systems as part of their account setup. The value of that notification didn't seem worth the extra friction for new users, so we crossed it out.
From here, just keep drawing and clicking until you think you've covered all your ideas. When there's a page for every button, it's time to move on to the final steps.
Involve the rest of your team
It's time to get buy-in from everyone that wasn't part of the sketching process. Gather your non-sketching teammates and walk them through the sketches. Explain what's on each page and what happens when you click each button. They'll have questions. Answering them may involve crossing things out or drawing new pages, but hopefully you can answer them with the things you've already drawn.
When everyone's satisfied, it's time to move on to the last step.
Estimate The Work
We think it's helpful to answer the question "Is it worth it to do this work?" and that requires some idea of the amount of work and the amount of value the work is worth. If that answer is yes, it's time to schedule the work. If the answer is no, it's time to cut your scope or cut your losses.
I know estimation is widely hated and with good reason, so I'll understand if this step isn't for you right now. Before using Burndown, I wasn't a big fan either. After using Burndown, I saw that having a good estimation process unlocks the door to great things like having an agile project management process, increasing profits, and never working overtime to hit your deadlines ever again. Also, Burndown made estimation fairly painless :)
We'll talk about all those things in future posts.