Ask way too many questions

Why ‘why’ is the most important tool in your product toolbox

Published in

The Startup

5 min readApr 28, 2016

This is Part 4 of a 6-part series where we share everything that went into building our product at Crew. Privacy be damned. Building Crew in Public is not just filled with glory. It’s filled with the struggles and doubt we faced creating a product.

When we first looked at how we were going to completely redesign our app, we started with undefined problems.

Then, we took broad strokes at defining the hairiest ones. How could the pieces flow together?

Although this resulted in more questions, each question we answered helped us define the solution to each product problem better. And we got closer to the point where we could take action and build what could work best.

The challenge with lofty, undefined things is the actions needed to start are usually unclear.

If you set a goal to write a book this year and put ‘write book’ on your to-do list, you will likely keep putting it off because ‘write book’ is not a clear action you can take.

Do you start writing a book by making an outline of all the chapters or do you start by writing the first chapter?

‘Write book’ is undefined. And undefined things are scary. They send your brain running. Usually to your inbox or Facebook.

Every day, important, undefined tasks lose to things that can seem urgent like email. It’s one of the pitfalls of to-do lists.

To win. To do the high impact, long-term things we want to do, we must break goals/tasks down into smaller parts, until we have a concrete set of ordered actions we can take.

If you want to write a book, instead of putting ‘write book’ on your to-do list, put the first action you should do. Like, ‘think of 3 ideas for the topic of my book.’

That’s much better. Now it’s easier to start.

Comparably, when building this next version of Crew, we started with lofty goals for our product and broke them down into smaller parts. Now it’s time to define our actions so we can start building.

We know more or less what we want to build but each feature still needs a deeper discussion to know how it will work.

What specific conditions must be met for something to work?

Are we considering all the use cases?

What happens if X doesn’t do X?

We took our list of problems and made a list of questions related to how each item should be built.

We did this as a Google Doc so we could comment on each problem individually first and then discuss our perspectives for how they should be built together.

This is one of the most effective ways to brainstorm for us. By spending individual time first, there’s less chance for social pressure to conform to ideas of others. We could form our own opinions without any influence from the group.

This allows for more perspectives to be brought to the table which can help uncover a better way to build something.

We all have blind spots. This is how you catch them.

For instance, here was a question related to creating a project agreement (which states what, when, and how work will be done before a project starts):

We all had different perspectives for how agreements should work. By allowing individual time for each of us to think how agreements could operate, we were able to consider more options and have a deeper discussion when we came together.

We had many other debates similar to this throughout the document.

After individually answering everything in this Google Doc, we met to discuss each item to make sure we were on the same page with each one. This was a long meeting. About 7 hours (with a break for cooking and eating dinner).

This meeting was crucial. A turning point. We defined many of the ideas and wild thoughts we had always wanted to build but hadn’t gotten around to.

Here’s a list of ideas we had been collecting for months (some items blurred out to protect customer info):

Theory became reality. And we could start building.

Yes, the answers we’ve figured out now will likely shift in the future as we build them but at least we’ve laid our path.

Building Crew in Public

Privacy be damned. Building Crew in Public is a series of 6 short essays on product design philosophy and the struggles we faced designing our own product. You can read the original, On The Road-inspired version on the Crew Backstage blog.