Skip to content

Our way of working

The Thinkmill Method

We’ve had the privilege to work on an amazing variety of projects over many years, exposing us to many and different kinds of teams and problems. Over time, we’ve developed a method for product development that helps us build compelling software.

This is the teaching material of this method. We use it as a resource when training Thinkmillers one-on-one in the principles, culture, and practices of how we work. It’s a living document that evolves as we evolve our practice. We’re sharing this method in the hope that it’s of interest, and maybe even useful.

What is the Thinkmill Method?

A way of approaching software design and development that increases the likelihood of shipping good and compelling software, while maintaining the wellbeing of the people involved. It focuses on team dynamics, silo-breaking, and shared responsibility as foundational for cultivating unified and productive teams.

It is not a framework, prescription, or a paint-by-numbers affair. It assumes (and requires) competent craftspeople who care deeply about the problems they’re solving and who know how to wield the tools of the trade. Like all good professional tools, there are few guard rails, and lots of sharp bits.

The Thinkmill Method comprises:

  1. Fundamentals – the principles and mindsets that underpin the Thinkmill method
  2. Team structure – the way we organise ourselves
  3. Playbook – the tools and processes for which we reach
The three elements of the Thinkmill Method (Fundamentals, Playbook, Team Structure) and their constituent parts

The Thinkmill Method in a nutshell


The basic principles and mindsets that underpin our approach.

  • Design is a team sport

    Design is a conversation and good-faith negotiation between multiple practices, not something that “designers” do, and others wait to build. We use “design” in the holistic sense, encompassing everything that contributes to a positive user experience outcome – interface, database, API, pricing, etc. Good and compelling products result from successfully integrating these practices into a coherent and compelling whole.

  • Design artefacts are an abstraction

    We use abstractions (interface designs, UX wireframes, entity relationship diagrams) to communicate and collaborate across practice areas. However, abstractions only approximate the actual product and user experience. As early and much as possible, work with or close to code.

  • Schema-led

    We follow a schema-led approach in our work. A schema (conceptual, database, or API) describes the domain in terms of objects and their relationships, and is an especially useful artefact that builds shared understanding between practice areas. When defined in code, it serves as a shared source of truth, allowing UX/UI, front-end, and back-end work to proceed independently with confidence.

  • Work in the open

    By working in the open, it’s much easier to stay in sync, and it enables the design conversation to take place with less friction. Working in the open means actively and regularly sharing your WIP with the team, and stakeholders. Doing so reveals gaps, mistakes, bugs, and dead ends, and it’s a highly efficient and accessible way to communicate context and status.

  • Stay synced

    By working in-sync from the start, building shared context and understanding together, and not getting too far ahead of each other, cross-functional teams will make better trade-offs and fewer compromises.

  • Build for user-experience outcomes

    People use the software we make. Therefore we hold positive user-experience outcomes to be the primary and shared goal (see design is a team sport). We frame goals in UX terms, and we make decisions with respect to and with awareness of their impact on the users’ experience.

  • Bias towards code

    A significant amount of time can be spent pushing pixels around a screen. Jump into code as soon as possible to validate assumptions and get a feel for how the real user experience is shaping up. Working with code will reveal blindspots that lurk in design artefacts.

  • Check your blindspots

    Similar to cars, our design tools have blindspots and limitations of which we need to be aware. For example, it’s hard to design for performance in Figma, a11y in a product spec, or for usability in a database schema. The team looks out for each others’ blindspots and ensures all facets of software (usability, accessibility, performance, desirability, etc) are considered and designed to create good and compelling products.

  • Mind the gap

    Gaps exist at the seams which join the practice areas. For example, a gap may exist between what the interface design calls for, and what the API currently allows — or, what the business wants, and what’s possible given an existing back-end. In practical terms, gap finding involves habitually comparing UI or UX spec against API or back-end ones, and looking for gaps between the two. Gap filling is simply the collective act of closing a gap, typically by changing a user interface, changing the system to enable it, or changing the scope/requirements.

Team structure

This is how we might organise a team of practitioners that follow this method. This is a general picture. Keep the principles, but it’s ok to vary the people and labels as needed.

Diagram of Thinkmill method team structure

There are many kinds of problems and multiple ways to organise people around them. This section is intentionally broad, leaving the specific team to apply the appropriate fundamentals.

Core solution squad

The core group is a cross-functional team made up of leads from multiple practices. Typically, this takes the form of a trio or quartet representing product, design, engineering, etc. More complex undertakings may call for additional and more specialised individuals.

The core solution squad “journeys together” – that is, operates as a high-sync partnership.

The objective for the core squad is to achieve a shared and cross-functional understanding of the problem, constraints and opportunities, and ultimately, the solution.

Core solutions team, working in a co-design partnership, builds shared understanding over time

Core solutions team, working in a co-design partnership, builds shared understanding over time.

Delivery squad

The delivery squad helps do and deliver the work. Depending on the size of the project or team, the delivery squad may just be the core solutions squad wearing different hats. This squad is unblocked and empowered by shared artefacts, and the shared understanding that they convey.

Shared understanding artefacts

As the team works together, the emerging shared understanding is documented in a range of artefacts as appropriate, which help to get and keep the group in-sync and aligned throughout.

The core team should use any and all tools and processes to help create shared understanding, but some common, particularly useful ones include:

  • Product & customer spec
  • Core concept modelling and/or Data modelling
  • Schema definition
  • Activity mapping
  • Route mapping and/or process mapping
  • User flows and/or wire-framing


The Thinkmill Method playbook is a library of practices, with guides, examples, and prior art, that aims to serve as a reference for teams working in this way. It aims to be highly practical and applicable, without being prescriptive.


Coming soon

We’ll be publishing our playbook over the coming months, starting with the core practices. Subscribe below to get updates when we publish new resources.

Subscribe for updates

We send a newsletter from time to time when we publish new resources, articles, and open source projects on the topics of software design and engineering, design systems, and process & practice.

Related resources

Boris (Thinkmill’s CEO & Head of Design) spoke about the our methodology at the Delighters meetup in Sydney, Australia. At that time we toyed with calling the method “Antifragile”, but changed our mind later.

A photo of Jed Watson & Boris Bozic together

We’d love to work with you

Have a chat with one of our co-founders, Jed or Boris, about how Thinkmill can support your organisation’s software ambitions.

Contact us