November 30, 2017
When I have a task to do, I like to jump right in.
If I have a copywriting project on my plate, I’ll start writing. If it’s design, I’ll open up Sketch. If it’s product strategy, I’ll create a blank note and start dreaming.
Getting started feels good. It makes me feel like I’m being productive and doing work that matters.
But it’s a mistake.
Quite often, much of my work breaks down when I present it to my team. I may find that they have a solution built on a different set of assumptions than me, rendering my implementation sub-optimal from their point of view.
Or, they may have different opinions about the underlying problem than me, resulting in circular, time-consuming conversations.
This isn’t their fault. It’s mine.
It’s my fault because even though jumping right into a task felt productive, I was actually being lazy. I spent nearly all my time on implementation at the cost of planning and getting clear about what I was trying to achieve.
Instead of immediately getting started on a project, I now always step back first and survey the project from a bird’s-eye view. Solutions only happen after I’ve gone through this process.
Here’s what I do:
Steps 1-4 typically take only 10 minutes or so as I’m purposely informal about the process. If I had to fill out a checklist or spend an hour going through these steps, there’s no way I’d ever do it.
Instead, I open up a blank note and jot down bullet points for each step. That’s it. Once I’ve covered the main issues in each point and feel like I’ve generated enough ideas, I pick the best one and get started.
Here’s the process in more detail:
What are you trying to solve? What’s the point of the work you’ve set out to do? Getting clear on the problem is like building a strong foundation - without it, you’ll be lucky to build something that can stand on its own.
It’s useful to consider metrics at this stage, if you have them. For Mealime, this may be something like “the metric completed_item for new users when they first visit the grocery list is low” - let’s try to improve it.
What outcome are you hoping for? Are there secondary or tertiary goals that you’d like to hit? I also like to reiterate metrics in this step.
For example, I’ll mention the completed_item metric again, but also add other goals like “Make this implementation bigger (literally) than our last one”, or “Reiterate how easy grocery shopping will be”, or “Try giving users a specific call-to-action to complete x,y,z items”.
Don’t forget this one, it’s important. Maybe you only have a small amount of space to work with. Or, perhaps the test you’re designing is meant to be low-cost and quick to implement, so your final recommendation shouldn’t suggest storing new user data (costly) or doing a full iOS release (time consuming).
Getting clear about what you have (or don’t have) to work with will make the next step - generating ideas - much easier.
This is the fun part! And it’s much more fun if you’ve completed the first three steps, as you already know what you’re trying to do, your primary and secondary goals, and the resources you have to work with.
Optional: before jumping in, you could reach out to your team and have a quick discussion about your assumptions - the problem, goals and constraints you’re attempting to solve.
If you timebox the meeting it shouldn’t take more than 15 minutes, but you may get valuable feedback before you spend the bulk of your time implementing your chosen idea. That’s a big win!
Otherwise, you now have clarity on what you’re trying to do with an idea that solves the problem, achieves your goals, and is mindful of your constraints. You’ve essentially de-risked your work and can confidently get started.
I follow this 5 step process for nearly everything I do now - sometimes even when drafting an email to friends and family!
It’s a short exercise that helps so much with clarity, team cohesion, and productivity. I can’t recommend it enough.