more info ⬇

@amattn

SW engineering, engineering management and the business of software

subscribe for more
stuff like this:

2020 11 03

WCWDIX: What can we do in 1 year, 1 month, 1 week, 1 day, 1 hour, 10 minutes.

One of the best tricks I’ve come across to make meaningful progress on any long term project is to start with an initial (typically long) time estimate, than play the “What Can We Do In X” game.

If you need a fancy mnemonic, use: WCWDIX (pronounced wick-widicks)

It works like this:

If you start with an initial, hypothetical estimate to build a product or feature of 5 months, ask yourself and your team: “What can we do in 1 month?”

One Month

This forces the thought process of Ruthless Prioritization. Typically, your must have features become should-haves and your should-haves become nice-to-haves. It’s important to be ruthless here. Strip the business down to the core, while still being usefull. Remember that the MVP of a car is not 4 tires on the ground (useless) but a skateboard or bike.

One Week

Follow that up with “What can we do in 1 week?”

This helps with the notion of what it takes to make a Useful Prototype. Hopefully this is mostly code/product that you can reuse over the longer journey. Importantly, you have prioritized faster and are cutting corners to get to a product point where you can put it in front of people. This builds technical debt, but it is almost always worth it because you are learning so much faster, earlier in the development process.

One day

By now, you know what comes next: “What can we do in a day?”

In a day, you can’t build much. But you can Fake Product. Sometimes this means wireframes in a mockup app. Sometimes this means wiring together no-code SAAS apps or even a spreadsheet and tools like Zapier to simulate the guts of your business logic. Fake Product is great for customer development or even early sales calls.

Another option is Market Discovery: spend a day doing market research. This is different from customer validation which typically happens after you have a product idea or prototype. Market discovery is more about finding a market that has pain points and the ability to pay to address those pain points, and ideally a market you can reach via known sales/marketing strategies. It’s important to do this process without any preconceived notions of product/solutions. Identify the pain first!

One Hour

“What can we do in an hour?”

Not much? Wrong! An hour is enough for Short Burst of Research. You can hold 2-3 customer development calls. You can setup up a landing page and blast LinkedIn, twitter and other social media sites to see if you can get any bites. You can do some google searches and look for evidence of your market hypothesis. You won’t typically get enough info here to be data, more anecdotes. But it might be enough to guide early thoughts/directions or help quickly identify a potential pivot that requires more investigation.

Ten minutes

Lastly “What can we do in 10 minutes?”

Even ten minutes is enough for Quick Info Wins. This is kind of a mini versino of Short Burst of Research. Send off a couple emails. You can buy a small ad campaign and measure how many clicks it gets over time. Counts cohorts in LinkedIn (are you marketing to poele in X profession? go check out how many people are in that profession to get a sense of scale). Anything you can do or setup to get Information from Outside your Team is great use of early hours on a project.

Wrapping it up

As you play the WCWDIX game, each step forces you to reduce “Time to Learn” by an order of magnitude. You can hopefully shine light as early as possible on the fact that you may be building the wrong product or solution.

The suggested activities (Fake Product, Market Discovery, etc…) are just examples. If you have alternative ideas that roughly fit in the respective timeframes, go for it!

However, the output of each step must make your smarter in some way. You could spend a few hours setting up a CI/CD system or learning about a new javascript framework. That’s work, and you have made technical progress, but you’ve learned nothing about your product, it’s viability in the market, or your ability to sell into a market. The bulk of your technical progress should (ideally) be after you’ve proven market and channel viability.

Companies don’t usually fail because they can’t build a product. They usually fail because they build the wrong product at the wrong time or they build the solution that ends up being wrong for a market that can’t or won’t bear the appropriate costs.

Always make sure to the best of your ability that you are building the right product!




you may also be interested in some of the greatest hits of amattn.com:

〜 Empathy as a Core Engineering Requirement

〜 Venture Capital Math 101

〜 You Should Foster a Culture of Readability

〜 The Customer's Semi-Lucid Trance State

〜 What is Engineering Management?




the fine print:
aboutarchivetwittertwitchconsulting or speaking inquiries
© matt nunogawa 2010 - 2020 / all rights reserved
back ⬆