No one size fits all

Recently one of my favorite internet companies, Basecamp, released a web book called, Shape Up, written by Ryan Singer (Head of Strategy).

This book shares how the Basecamp team ships new products or features. Their approach is a little different from most, an opinionated one.

I like it. It helps me to re-think the process that I've been practicing up until now.

The way they name the phases is more describing the condition instead of the activity/task.

  • Abstract,
  • Shaped, and
  • Concrete.

I found that the idea of abstract to the concrete creates a space for us to flexibly think, choose, and evaluate tools/frameworks to be used effectively in a project. When building a new product, or a new feature, many different variables influence our process. Sometimes what we do in one project won't be exactly the same in another project.

Hence, no one size fits all.

Nevertheless, having a detailed and prescriptive workflow still necessary. It works as a standard, as a clear baseline that maintains interaction between many roles.

Either your workflow is more flexible or not, we always need to think critically.

Having more freedom must be balanced with an immense responsibility to have a rationale behind which approach/tool we use.

If you work with a rigid workflow, be critical in every process. Check whether you should play it by ear.

Here are some questions for you to take a little pause and question your process:

  • Do I need to do {...} in this project?
  • Why do I need to do {...} ?
  • Do I need to adjust {...} because of our stakeholders?
  • What is the expected outcome if I do {...} ?
  • Do I already have enough evidence or supporting data to support the idea?
  • What can I do to understand more of the user problem?
  • Can I create a realistic enough prototype for testing in front of our users by using {...} ?
  • How to prove this hypothesis?
  • Is there any other way, which more effective or practical than {...}?
  • What could be better from the previous project?