Product Engineering Principles at Click Travel

Note, thist post was originally published on

Over the past year, the Click Travel Product Engineering team has grown to a team of over 50 people!

As we continue to grow, it’s crucial that we create a shared understanding of how to build good software. This is equally important for enabling our existing engineers in making decisions and prioritising work, and also for our incoming engineers in knowing what to expect and how we work.

So, at our last ‘Product Engineering Day’, we introduced a set of Product Engineering principles to help foster alignment and collaboration within our Product Engineering teams. We established that these principles should be taken as guidelines — not absolute rules that should be followed without pragmatism or thought.

Taking inspiration from Hector Barbossa from Pirates of the Caribbean…our Product Engineering Principles are intended to be guidelines, not absolute rules!

Since we introduced these five Product Engineering principles, we have been pushing ourselves to share and refer to our principles a lot in our day to day (more on this in a bit). We also plan to review and update them every year or so, to ensure that they’re still guiding us to the results we want to achieve.

Our Product Engineering Principles:

Learn, Build, Measure (🔍,🧱,📏)

This principle has been inspired by ‘Build, Measure, Learn’ — a lean startup process made famous by Eric Ries. As we already have an established product, we want to start from ‘learn’ rather than build. We debated whether we should express this as ‘Hypothesise -> Experiment -> Test -> Insights’ but we felt that was too prescriptive as to exactly how to embody this practice.


To encourage and maximise validated learning about our product and how our customers respond to changes we make. We believe this approach will help us make more informed decisions about where to take our product, in order to achieve our vision of reducing the cost and complexity of business travel for everyone.

Click’s Product Engineering Principle: Learn, Build, Measure.
[Presentation template by Slidesgo]

Why before how

This principle is designed to encourage us to start a piece of work by first deeply understanding the problem before writing code or ‘solutionising’. We believe that the success of any solution is based on fully understanding the problem that needs to be solved.


There are two core reasons for this:

  1. Rushing into the build without truly understanding why we’re doing something often ends up in a lot of re-work. None of us enjoy working really hard to deliver something, only to get feedback from the requester / customer that it doesn’t actually solve their problem and you need to start over. To avoid this, we need to be thinking up front.
  2. Often, it’s easy to get into a cycle of delivering the ‘very important person’s’ ideas before and above everything else. Most of the time, these ideas have no cohesion and are constantly changing, which makes it easy to veer off track from the company’s missions and objectives. Even if the idea comes from a very important person, we need to take time to understand the why in the request, to avoid wasting time building something of little value.

Our ask: Before starting to code, pause to evaluate whether the problem you’re being asked to solve is clear and valid. When coding consider how you or someone else may interpret your work in the future and how easy it is to understand, refactor, and remove.

Click’s Product Engineering Principle: Why before how.
[Presentation template by Slidesgo]

Progress, not perfection

This principle was inspired by the fact we had just completed a huge transition project from a monolith codebase, to serverless microservices built in Node.js on AWS Lambda.

Due to the constraints of the transition project, we were delivering feature parity in ‘big bang’ style batches rather than incremental improvements. We wanted to get back to delivering work in small, meaningful pieces, by keeping pull requests small and focused, and ensuring work was getting put in front of customers as soon as viable. We are fortunate that we have the ability to push to production immediately — we want to get back to leveraging this!


We believe that fast feedback loops are important to successful, predictable and sustainable throughput.

Click’s Product Engineering Principle: Progress, not perfection.
[Presentation template by Slidesgo]

Constructively challenge, debate, commit

Conflict, tension and debate are healthy as long as people focus on the ideas and issues, and not each other.

We want to encourage the team to constructively disagree and debate a decision whilst it’s being made, but once a decision has been made, everybody must commit to it, regardless of whether you agree or disagree. It also relates to the intent behind ‘Progress, not perfection’.


We believe following this approach will allow us to achieve faster customer feedback loops as we’ll be able to get things into production quicker if we don’t spend time in ‘analysis paralysis’ whilst trying to reach a consensus. The idea is that we want to encourage people to provide alternatives, rather than a straight disagreement.

Click’s Product Engineering Principle: Constructively challenge, debate, commit.
[Presentation template by Slidesgo]

Unblock others whenever you can

We can’t take credit for this one, we respectfully copied this directly from FT and Monzo! We believe this is incredibly important.


If someone is stuck, helping them is an incredibly high-value use of your time: spreading knowledge and skills levels everyone up. If someone is waiting on you for a code review, prioritise it ahead of writing new code yourself.

Click’s Product Engineering Principle: Unblock others whenever you can.
[Presentation template by Slidesgo]

How did we come up with these principles?

I gathered my immediate team together (Robin — Chief Product Engineer, Hayley — Product Team Lead, Stuart — Head of Engineering Management, Golnaz — Head of Engineering Enablement) for a team off-site.

We ran through a “Be the kind of team you want to be a part of” exercise which we had learnt about in Julie Zhuo’s (@joulee) highly recommended ‘The Making of a Manager: What to do when everyone looks to you’ book.

This consisted of three parts:

  • Understanding the current team (in our case, the Product Engineering department)
  • Understanding our aspirations
  • Understanding the difference

After understanding how we wanted Product Engineering to operate, we thought about what behaviours we would need to encourage in order to achieve that. After many post-it notes and a few iterations, the first set of our Product Engineering Principles were born!

Click’s ProdEng Leaders during the team off-site

Living the principles

When developing these principles, we were acutely aware that we didn’t want to spend time developing them and then find they gathered dust hidden on an internal wiki page somewhere. We want them to influence our Product Engineering culture and guide us in building a product that delights our customers.


As we’re a distributed team, putting up posters solely in our HQ in Birmingham wouldn’t cut it. Instead we put up large posters in the office, and then sent smaller versions of the posters to every distributed person to allow them to decorate their home offices!

Some people decided to have their posters placed behind them, so when they are on zoom calls, they become visible. Others chose to scatter them around the room — changing the placement every so often to keep them top of mind.

Click’s Product Engineering Principles at home!
Click’s Product Engineering Principles at the office!


We created a dedicated slack channel for discussions about the principles, and a place for people to share photos of themselves with the principles.

We tried making a slack bot responder for each time someone mentioned one of the principles in slack, but quickly found that was driving the opposite behaviour — people stopped using the phrases in fear of the annoying bot response!

Some people have chosen to change their profile photo to show them holding a specific principle to subtly re-enforce them when chatting on slack.


We use a ‘Weekly Snippets’ process as a mechanism to provide visibility to the entire department, and our stakeholders, capturing what impact each product engineering team has made, what they are blocked on, and what’s upcoming.

Each week, teams provide a written weekly summary in a dedicated slack channel, then we hold a short ‘snippets meeting’ where the Engineering Leads and Product Owners (and anyone else who fancies) come together to go through the highlights of the week (celebrations, blockers, advanced warning of upcoming items, overview of incidents).

We are experimenting with focusing on a single principle each week, and asking teams to capture in the written snippets and in the snippet meeting, how they have been living the principle that week, or what challenges they have faced when trying to live it.

The idea is to bring the principles into active conversation, so that becomes standard operating procedure. It’s also a way for teams to share knowledge and tips on how they have lived the principles in different ways, which we hope will help us avoid the trap of being overly prescriptive on how to operate and therefore missing the intent behind introducing these principles.

The next iteration

In the spirit of living the ‘Learn, Build, Measure’ principle — we’re in the process of measuring how effective our current approach of embedding these principles into our day-to-day work is, then we plan learn and iterate. We’re also still on the lookout to find other effective ways to influence our culture with them.

If this sounds appealing then come and join us — we’re always on the lookout for talented people to work with!

About the author

I’m an experienced technical leader who is passionate about technology and building high performing multi-functional teams to develop brilliant products.

When I’m not at work, you can find me on poolside coaching some brilliant Age Group swimmers at Edinburgh Synchronised Swimming Club!

Sarah Hale
(@sarahjane_hale on twitter)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s