The expression “eating your own dog-food” is about using your own product, so that you see first-hand the same thing your customer does. This is a really powerful approach, and definitely worth doing! The aim should always to to build products that, as a basic minimum, meet the customer/user’s needs, and do so in a way that is “nice”. This is obviously quite subjective, and we’re clearly going to want to get real customers’ opinions and feedback as well, but one of our core values is to start from where we are now – and right now, in the very early days, our own feedback is easy to get and gives us a good starting point.
We’re building Agile Labs as a product to help people build products. We can kind of recursively use Agile Labs, as we build it, so that we become our own first customer. If something doesn’t work for us, then it probably won’t work for anyone else either – so this gives us a great early validation test.
There’s clearly a “chicken and egg” thing here… we can’t use things that don’t exist yet! However this is great, because we can leverage this to tell us what to build first. In the absence of an actual system, what we actually did is draw things out on paper or whiteboards. We can then capture those tools and techniques to become the backbone of the software product.
For example, here’s our (actual) whiteboard that we’ve been using while working on the journey from visiting the public home-page for the first time to having an account and the basic data in place to start working for real (apologies, my hand-writing is rubbish!)
We didn’t try to force ourselves to work in any particular way for this – we just grabbed a whiteboard and pens, and did what made sense to us. If we didn’t like how we were modelling something, we just wiped it off and tried a different way. When we had what we needed, we can then look at this and think about how to model the same thing in software. Trying not to give away too many spoilers, but the meta-features – like scoring the areas of the system to prioritize what to improve next – here will be added pretty soon!
As another example, we use a combination of paper sketches and “code sketches” to try out ideas fast. Here’s actual code from an early prototype that shows us playing with data structures to capture “Goals”, our core day-to-day building block:
The idea here is that we can very quickly knock up data that represents what we’re doing – and we can get a feel for whether it suits what we’re trying to do or not. Our next step is to build a prototype for this, and see whether it’s actually fun to use. By the time we go through a few quick iterations like this, the designs stabilize. By using our own example, we nearly always find some aspect of the design that we can improve, and the results are – we think – much better for it!
So if you’re building a product, why not see if you can leverage this idea. Get a simple setup where you can pretend to be an actual customer, and use the product the same as they would. The observations and insight you can get from this are often surprising but nearly always valuable!