Build to think
One big change I’ve made in my habits recently is to be comfortable with creating something badly. I accept that the first cut of whatever I do will be terrible, but at least something exists, and when it exists we know where it sits in comparison to where we think it should be. Perhaps we only know ‘where it should be’ by first finding out where it shouldn’t.
I saw the term ‘build to think’ recently which captured it perfectly. If you’ve been tasked to create a product roadmap, instead of speaking to multiple stakeholders and iterating over emails and endless meetings, just create one with what you know… what you think. Take a ‘first stab’. When people see this they can start filling in the gaps, rearranging the form and clarifying their view.
In design thinking there is a beautiful concept called “Prototypes drive requirements, not the other way around”. That concept is building to think. It’s the act of knowing that we don’t know what we want until we see it, so lets show something as early as we can. This can be done quickly and cheaply. If it’s requirements you are gathering for a new solution, immediately do some hand drawings of the 3 key screens where you see these requirements existing and start sharing that. You’ll find that people will notice gaps that they absolutely could not see if it were written as user stories.
I also heard the term “progress not perfection”, another great caveat when sharing your artefacts. The guy that is all talk and no output is the one that’s simply afraid to create a knowledge object, he’s thinking too much and doesn’t realise the importance of having something tangible to share.
If you’ve got something important to do, build something quickly and put placeholders or guesses in the areas you’re unsure of. What you’ll see happening is that this artefact will become the ‘official’ item over time.
Build to think. Prototype to get requirements. Progress not perfection.
