We created Loomery to make it easier and faster to ship great digital products. We’re a young company but we have pretty strong opinions on how great products are built quickly. So, we’ve attempted to capture our approach in six principles that our team follows and promotes, six beliefs we think are important that guide our behaviours and decisions. 

You could even describe them as anti-principles; as they describe what we don’t want to do as often as they describe what we do want to do. The principles are:
1. Products not slides
2. Do then document
3. No data, no debate
4. Business cases lie
5. Learn on the cheap
6. Start by shipping

In this series of posts we dive into the six principles in turn to explain what they mean and how we apply them day to day. Today we’re discussing our second principle “do then document”.‍

Principle #2 - Do then document‍

As you might be able to tell, at Loomery, we have a bias for action. Just as the Agile manifesto prioritises “working software over comprehensive documentation” we place product progress above all else.  

After all, you create software with code (or even no-code!), not specs or documentation. That doesn’t mean nothing is written down. Capturing stories has value, as does documenting an important process. For good governance and to avoid repeating previous mistakes, documentation can be crucial.

But we believe in ‘just enough’ documentation for the task at hand. What’s the minimum that must be captured for everybody to stay aligned, informed and unblocked? We also believe in documenting things as late as possible - only before you actually require it. That way you document what you have actually built, rather than what you think might be needed.

In our work creating a community app for the leaders of companies across a private-equity portfolio, we wrote down very little in advance of the build: a handful of user stories, the key things we learned from research. Then we put all our effort into the product, shipping v1 in just 2 weeks. Product guides and other real documentation was all created afterwards - which actually made the documentation quicker to write too.

Hear what our team have to say about how we apply this principle:

‘Designers are no longer required to write lengthy specifications thanks to helpful tools such as Figma and Webflow. Handing off to developers is as simple as giving them access to inspect the code. To optimise this workflow there are a few things you can do earlier in the design process to set up your files to improve handoff…

Solve the valuable problems through design and prototyping. Then write the tickets/ acceptance criteria with the developers and product managers.

Do the most critical tasks that add up to a valuable change before doing any kind of documentation because strategic progress is much more important than articulating everything. It’s also really important to step back and assess whether documentation is actually a valuable output and whether there’s a better solution to fit your needs. For example, alignment might be easier to achieve with a 2 minute conversation than 15 minutes spent crafting a doc to capture the right words.

If documenting is the right way to go, it definitely shouldn’t be created in a user vacuum, it should be a living document that changes throughout time and it should be reflective of what you’ve learned creating and launching the product, grounded in customer reality. Ideally it’s maintained and updated, rather than something that’s fixed at the time of a previous product reality.’

‍- Joni Mortimore, Lead Designer‍

‘Documentation can be useful (and should be treated like a product; updated, maintained and lean). Accepting that we work in an imperfect environment where you can’t keep the same product team the whole time; there will be change; there will be breakdowns in communication, documentation is sometimes useful for sharing why a thing exists or sharing how to think about something.

But too often that documentation is written before anyone has touched the product so it embeds assumptions you have on how your users are going to interact with the thing.’

- Brett Thornton, Founder

We’d love to hear what you think about this so get in touch.  We’ll be talking about our third principle “no data, no debate” next week so look out for that. Thanks for reading.

Loomery is a faster path to product progress. We deliver trusted teams, when you need them. Our community of expert makers, remote teaming approach and flexible partnership model mean we can demonstrate progress on your priorities next week, not next year.‍