How to Optimise Your Kanban Board (in under 5 minutes)

I’ve mentioned Kanban Board optimisation a number of times in our recent videos, so I’ve put together a quick video to demonstrate what I mean. Sometimes simple changes can make a big difference.

Discovery: The dirty word of digital development

“Andy Dufresne…who crawled through a river of sh** and came out clean on the other side.”—The Shawshank Redemption

In The Shawshank Redemption, Andy Dufresne teaches us that we have to be prepared to get down in the… mud… if we want to come out clean.

That’s how I feel about Discovery—the dirty word of digital development.

I rarely fight as hard for anything as I fight for robust discovery at the start of a project—because it’s here that we learn the most critical thing about our client and their project:

What it is they need.

This might sound uncontroversial—a no-brainer even—but in practice discovery can be a drop-down knuckle fight… with the client on the other side of the ring.

No matter. If we want to accelerate our digital delivery, it’s a fight we have to win.

You can’t always get what you want

The main point of conflict is pretty simple. When a client comes to an agency they almost always know what they want. An app. A cloud service. A website. 

Our painful job—our duty—is to dig past what they want and get to the core of what they need.

And that takes time and effort.

It’s natural for a client to resist this. They’ve done their internal planning and due diligence. They may even have written an RFP. To clients, discovery often looks like an additional cost or pointless delay. 

“We’ve done the discovery for you. The board wants progress. Let’s just get on with it.”

I’ve seen some agencies (and worked on some projects) where the team did just “get on with it”. No discovery beyond the RFP, no investigation or pushback. You want to pay us to build an app? We’ll build you an app.

And six months later there it is… an app that looks fine and works fine… but doesn’t solve the client’s underlying problem.

Because the agency—let’s call them Done 4U— never fully understood the problem. How could they? They never did the work.

Why we’re in the business of solving real problems

Leaving aside the problems of Done 4u’s client, we might think that the agency did okay. They answered an RFP, delivered the project, and got paid. Happy days.

But the client isn’t happy. To them, the project was a bust. How likely are they to come back to Done 4U with the next project?

The answer is obvious.

By surrendering on discovery, Done 4U’s talented team has lost the opportunity to solve the client’s problem, build trust, and open a long-term relationship. 

(If you’ve read the first article in this series—on the principles of accelerated digital delivery—you’ll remember that trust is number one.)

It’s natural for clients to resist discovery, but if we can truly understand the problem, we have the opportunity to consider a range of solutions that might be better, faster, or cheaper.

• Not a new website, but a change to their existing one.

• Not an app on Android and iOS, but a web app to test the proposition.

• Not a bespoke application, but a customised version of an online service.

If you’ve never seen a client’s face when you suggest something that will solve their problem in half the allocated time and budget, I urge you to try it. It’s a special moment— that builds trust and long-term relationships.

Of course, discovery doesn’t always uncover some big unknown opportunity. Very often, we end up doing a version of what the client thought they wanted. But even then, we still move forward with a better understanding of the landscape ahead, of the business goals, success criteria, and risks.

Discovery is about going slow to go fast. So let’s look at how we do it…

The four steps of Discovery

When I start a Discovery process, I’m looking for clarity in four areas. 

1. Business goal (the problem to be solved)

This is mostly what I’ve discussed above: What’s the underlying problem that the business is seeking to solve (or the opportunity they seek to take advantage of). Common business goals include:

• Increasing customer conversions.

• Reducing operational costs.

• Enhancing user engagement.

• Improving efficiency in service delivery.

Clearly defining the business goal ensures that the digital solution we deliver can contribute directly to a measurable business outcome.

2. Digital goal (the solution)

Here we ask a critical question: Is the proposed digital goal the most effective way to achieve the necessary business goal?

If not, we have the opportunity to take a breath and explore different solutions. As an extreme example, a friend who worked for IBM was approached by a Premier League football team that was redeveloping their huge stadium and retail outlets. A big part of the RFP was a digital wayfinding experience (their words) that would guide visitors around the new site. This was certainly a possible solution, but good signage would have likely served far more people at a far lower cost.

The project did not proceed.

3. Risks and assumptions (RATS)

In my experience, few RFPs or clients have truly taken the time to assess the risks of their projects and the reasons they might fail.

This is a critical step, and thinking it through can often open up big questions that no one has considered. For example, I worked with a high-street bank that was developing a service to support small businesses. The RFP laid out the website they wanted, complete with video tutorials that covered all aspects of small business growth.

On its face, this seemed like a sensible opportunity to work on. Small businesses are the beating heart of any economy, and human inertia means that if you capture a company’s banking business early, you are likely to have it for a long time.

And yet, the opportunity was built over a huge and untested assumption… that small business owners would see this big bank as a credible source of startup advice.

When I asked this question in the discovery session, no one had an answer. No one had tested the idea nor surveyed the target audience. To misquote the fantastic movie above: If you build it… no one will come.

Here are some questions worth asking:

• Will customers adopt the new solution?

• Are internal processes equipped to support it?

• What external factors could impact success?

Find your Riskiest Assumptions to Test (the RATS) and test them as part of the discovery process. 

(A simple survey of the bank’s users would have given them the confidence to make the investment, the opportunity to address a perception problem, or the chance to create something that was attractive to the target market.)

4. Success criteria (KPIs)

This is where I see a lot of agencies getting nervous. When we define specific success criteria based on real business numbers, things can seem a lot harder. As a reminder, our notional agency Done 4U could claim success when they delivered on the project. They could add the client logo to their website and create a case study, even though the work did not deliver the result the client wanted. 

Here’s a hard truth: If we want to do great work, we have to put our money where our mouth is and measure our impact.

Measuring success requires well-defined Key Performance Indicators (KPIs) that go beyond general aspirations. Examples include:

• Reducing customer service inquiries by 20%.

• Increasing app conversions by 15%.

• Achieving a 2-second page load time.

Some agencies resist genuine KPIs for understandable reasons. However good your new customer service app is, the client may not get their 20% reduction in support inquiries if they underpromote it or shortchange the hosting. Some things are always outside our control.

But that’s why the whole discovery process is important. We don’t set KPIs with our eyes closed or (this is the classic) take the suspiciously round number that the client is aiming for at face value. We dive deep into our client’s world. We find our RATS and test them. We do discovery. 

Then we set realistic KPIs for the project with our eyes wide open… because later on we’ll want to prove that we delivered a genuine business benefit.

And even if we don’t meet the KPI—which happens sometimes—having a realistic target will tell us if we are heading in the right direction, and help us improve future interventions.

A stake(holder) in the ground

Woven through the four steps above is an understanding that every project has different levels of stakeholders with differing priorities, and we only win when they all win.

In the banking example above, the client wanted to attract new small business customers, but the customers wanted to build a small business. Those goals are related but not the same.

Or take the creation of a Content Management System (CMS).

• The client (marketing or IT leadership) may prioritize integration with existing systems.

• The customer (content creators) requires an intuitive and efficient interface.

• The end-user (website visitors) needs a seamless browsing experience.

Discovery allows us to consider the needs of all stakeholders, ensure that they are aligned, or identify what needs to be done.

If I can’t align the needs of all the stakeholders—like rings on the ring toy above—I won’t proceed with the project.

Discovery is a conversation, not a meeting

Discovery shouldn't be seen as a one-time workshop or a static document that gets dumped in a drawer—but it often is. For some reason, the valuable insights from discovery often get forgotten when the rubber hits the road. Phew, everyone thinks. Now that’s done we can do some actual work.

But that’s not how the best agencies work. Spoiler alert: Things change during projects. Business goals shift. People move on. We learn ever more about our clients.

I’m not saying that we should constantly be moving the goalposts of success, simply that hitting a goal is more like sailing a yacht than driving a car. We know our destination, but to reach it we must take account of the shifting winds and ebbing tides.

At its best, discovery is an ongoing process that:

• Keeps us focused on the right goal.

• Reduces costly project pivots by validating assumptions early.

• Strengthens trust between agencies and clients.

• Identifies new opportunities beyond the initial scope.

The best agencies—and their clients—continue to refine their discovery insights months or even years into a project. It’s not a meeting, it’s an ongoing conversation.

Final thought: Slow down to speed up

Each of these articles is written in service of accelerating your digital delivery practice. On its face, the time we take to do discovery can often seem like slow time—which gives me the opportunity to remind you of the classic bear joke.

Here’s Benedict Cumberbatch in The Imitation Game:

The point, of course, is that we go slow at the start to go much faster later. 

I’ve lost count of how many projects I’ve seen streak away like lightning… racing towards the wrong destination. (I’ve led some of them, and the result is never great.) At best there’s rework and overruns, at worst the project fails.

I solved that, years ago, by getting serious about discovery, and convincing my clients to do the same.

Start slow. Find your bear(ings). Then accelerate away.

Matt

P.S. If you’ve never seen The Shawshank Redemption, do yourself a favor and go watch it.

Bonus: Watch us discuss the way we do Discovery 

Creating the space for your team to focus

It’s circa 2009. I’m a contractor for a major telecoms company, leading one of their smaller development teams.

It’s a normal day until my Boss — the Head of Digital — taps me on the shoulder.

“Matt, would you come into a session with us please?”

“Uh… Sure.” 

I do my best to look relaxed, but my heart rate is climbing. I know that the company isn’t meeting its digital goals. My small team would be an easy target. My heart rate clicks up another notch.

I like this job. I need this job.

When we reach his office, I can see another senior manager inside. There’s nothing normal about this.

“Take a seat,” my Boss says. “We want to talk about what it is you’re doing?”

“Uh, this week’s sprint is to—”

“No.” He leans forward, cutting me off. “We want to know why your team… of five… is outperforming all of our others.”

What I learned from Tim Ferriss

In my article on ownership, I said this about the responsibility of leaders:

If we want our teams to take ownership seriously, we need to give them the time and space to do it. That’s easy to type in an article, of course, but it is infinitely harder to do.

We all know why. The world of work has only gotten louder. When I first read The 4-Hour Work Week by Tim Ferriss, I remember being impressed with—and implementing—his email autoresponder strategy. My responder at the time read something like:

Hi there, 

Thanks for your email. In order to focus on work, I check my emails at 11.30am and 4.30pm. If your message is urgent, please call me on XXXX XXX XXX.

Thanks, Matt.

Twenty years later, the simplicity of this seems almost quaint. Back then, all I had was email and phone. These days, I have email, Slack, Microsoft Teams, LinkedIn, Figma, and Calendar notifications. Many of these involve multiple accounts for different clients.

And yet, the simple premise of Ferriss’s argument holds. If we want to improve our productivity and focus, we need to batch our tasks.

The 2% difference that makes the difference

The two managers study me from across the table, the challenge still hanging in the air.

“We want to know why your team is outperforming all of our others.”

I smile. I can’t help myself as the tension washes out of my body. “Are we? That’s great.” 

My Boss makes a face. “It’s good for you, it’s not so good for everyone else unless we can figure out what you are doing differently.”

I nod. “Okay, tell me what they are doing?”

Over the next few minutes we go over how the other teams operate. It’s standard stuff. Standups. Sprints. All that. In fact, ninety-eight percent of it is exactly what we’re doing in my team.

And yet, the 2% difference stuck out like the crack in a phone screen.

“They have no time to focus,” I say.

How much work can you do in a day?

The answer, of course, is it depends.

In my view, the typical 8-hour day allows for 4.5 hours of focused work, but only if the day is set up correctly. Most people and companies manage far less. Instead of focused work, they peck and scratch at projects between incessant interruptions.

The 2% difference that made all the difference to my team’s performance was simple. I batched as many of the “interruptions” as possible into specific parts of the day.

In recent years, authors like Cal Newport and Nir Eyal have popularised this concept as Timeboxing, but I simply thought of it as clearing the decks so we could do what we were paid to do. Deliver.

The psychological principle behind timeboxing is Implementation Intention. When we set aside specific time to do something, we are far more likely to do it.

How we structure our day to optimise focus

For the teams I lead, the goal is to catch all the communication and interruptions into the morning.

In practice, this batching means:

• 9am-midday: Meetings & Collaboration
  The first few hours of the day are reserved for standups, pull requests, stakeholder discussions, and “office hours”. The goal is to remove blockers and ensure that everyone has everything they need to do their 4-5 hours of focused work.

• 1pm onwards: Focused Work
  Once collaboration is over, leave people alone to do what they need to do. 

That’s it. Like I said, the core of this is very simple. The biggest pushback I get is that this is too simplistic… that life doesn’t really work this way.

And often, those people are right. 

Implementing focus time can be difficult, especially in environments where interruptions are the norm. But this isn’t about slavish adherence. It’s about creating a meaningful default that works to everyone’s benefit, especially the clients’. Yes, sometimes you’ll have to take a call in the afternoon. That’s no reason to be ruled by a tsunami of noise.

Baby steps towards a focused work schedule

Setting up any new behaviour is hard. Here are some simple steps I’ve used to help teams move towards the goal:

1. Educate teams and stakeholders – Communicate the benefits of deep work (for everyone) and set clear expectations so everyone knows where they are.

2. Don’t start focused work until everyone has what they need – Ensure that morning meetings provide all the necessary information to make deep work sessions productive.

3. Use calendar blocking – Set visible “Do Not Disturb” times in team calendars to reinforce focus hours.

4. Encourage ownership – Empower product owners and leadership to shield developers and designers from unnecessary distractions.

5. Be role aware – Some roles are inherently outward-facing and benefit from longer “collaboration windows”. (That’s fine… These are often the roles that protect the core team from endless distractions.)

Don’t just try it. Make it your default.

Based on long experience, here’s what I predict will happen when you try to prioritise time for focused work:

1. It will be hard and you’ll get some grumbling.

2. The team will quickly grow to like it (the clients might take a little longer).

3. You’ll get more done with less stress. You’ll be over the hump.

4. Something will derail the whole endeavour.

5. You’ll be tempted to go back to the way things were (after all, it’s just easier).

That last point is the danger zone because real behaviour change is hard. It’s not about the start — because we all like shiny new things — it’s about getting back on the digital horse when you get knocked off.

I’ve failed at this often. Stuff happens, especially when you are dealing with large, complex projects. I’m often pulled out of focus, but that’s not my default.

My default is space, focus, and delivery. My goal is to have more good days than bad days. Because — trust me — good days compound.

By prioritizing deep work, your team will significantly enhance their productivity and impact. I know that from long experience… and our clients know it too.

Structured focus beats scattered multitasking every day of the week.

Bonus: Watch us discuss these ideas

How To Create Ownership Within Your Team

In this article, I want to ram home the importance of ownership and responsibility for highly-performing development teams. 

We’ve talked about trust as the foundation of accelerated digital delivery, but trust is a byproduct of a consistent, team-wide pattern: Doing what we say we’ll do.

Why it’s always our fault responsibility

Delivering on our promises shouldn’t be a controversial idea, and yet our industry suffers from an epidemic of missed deadlines, stalled projects, and ballooning budgets. Of course, none of these things are ever our fault. It’s other people that are the problem, or poor processes, or constantly changing requirements.  

Sounds familiar, doesn’t it?

I missed many deadlines in my early career. Some were genuinely unavoidable, but many gave me that “bad curry” feeling deep in my belly. Could I have done something differently?

In my later role as a consultant, I’ve worked with numerous struggling development teams. Many are watching helplessly as deadlines whizz by, and often teams stall, often descending into blame and name-calling. “I did my best,” people say, “but I’m not responsible for what happened before/after it left my hands.”

We’ve all heard and we’ve all done it, but here’s the thing: I never hear that from highly-functioning teams or people. They think about the work in a different way.

This entire series is about accelerating delivery, but none of the principles and tactical advice matter unless people take real ownership of the work.

So let’s take five minutes and talk about how you and I can take responsibility to help them do it.

There is no “I” in accelerated digital delivery (uh, what?)

Let’s start with the obvious. In digital development, we are generally paid to do something specific. We’re a team leader, a product owner, a designer, a developer, a UX writer, or whatever. We are valued because of our specialism, our experience, and our ability to execute in that field.

But wait. Our specialism is really only valued in relation to the wider team. In the long run, no one is paid for a specific skill, they are paid because they were part of a group—a team—that delivered something valuable.

No delivery. No jobs.

Common sense? Of course, but then again, I’ve met plenty of otherwise talented people who seem happy to wash their hands of everything outside their area. “I’m not a designer,” they say, “how can I be responsible for good design?”

To be clear, I don’t believe that developers should “do” design any more than designers should “do” development, but 20 years of experience have shown me that caring about the work beyond your silo is highly correlated with excellence.

So how does that “caring” manifest in the real world?

Who’s the real client?

As I’ve said before, the handover is a critical focus of accelerated digital delivery. When we do it well, work flows smoothly through the system, when we don’t, projects stall or go backwards.

To illustrate this, let’s imagine that a “siloed” designer “throws” some wireframes over the wall to development without proper support or documentation. A good developer may be able to do the work, but it won’t be an efficient, accelerated workflow. At best there will be bitty back-and-forth conversations, at worst there will be misunderstandings, rework, and stress.

By contrast, imagine a designer who sees the developer as their client. This designer isn’t just doing a design, they are taking ownership and making sure that their “client” has everything they need to pick up the project and run with it.

Depending on the processes in place, this might include:

• A short handover meeting (that the designer arranges and leads).

• Designs that are signed off by the client (to minimise future changes).

• Wireframes prepared for both desktop and mobile views.

• Copy that’s finalized in collaboration with a content writer.

• Clear documentation and videos explaining the work (and the thinking behind it).

• A follow-up chat to address any issues.

This is a concrete example of “caring beyond your silo”, and works all the way down the line. If the developer is handing the project over to Testing, they should see Testing as their client.

Teams that work this way function smoothly by default. There are always issues to resolve, but they are far fewer because no one is “done” until the next person in line has everything they need.

Some people (diamonds) naturally work this way. They make it their business to understand what the next person needs and deliver it. Others—perhaps the majority—need help to make this step and understand what “done” looks like for them.

And that’s where we (and our processes) come in.

Defining what “done” looks like

If we want people to take ownership seriously, we need to define what that means. In other words, what does “done” look like for each role within the project?

Building on the ideas above, this can be achieved with:

1. Clarity in roles and responsibilities
   Every team member must understand their role in the delivery process, who they are handing off to, and what is required before they can hand it over.

2. Checklists
   These requirements are codified in a checklist that must be completed before the project moves on. (Checklists remain the most undervalued assets when it comes to delivering our work with speed and precision.)

3. Structured handovers
   The baseline for this—believe it or not—is simply that a formal handover actually happens. I’ve been parachuted into teams where there was no handover process, and it was all too obvious in their performance. If you aren’t doing it already, start. Make it a formal process and improve as you go.

… which leads us to another critical aspect of ownership.

There is no “best” way

I’ve been working in digital development for decades, but I’m well past believing that I have the “best” production process. All I can claim is that I have the best so far for my particular teams and their needs.

We don’t carve our processes in stone and demand that others follow them unthinkingly, we write them in digital ink and challenge others to improve them.

Better ideas are everywhere, especially when we break out of our silos and look at what’s working elsewhere. We didn’t always ask our designers to create videos of their user journeys, but an idea sparked by YouTube demos has become a valuable part of our handover process. I can’t remember exactly who suggested it, but it was just as likely to have been a developer or product owner as the designer themselves.

Ownership isn’t just about meeting deadlines and doing good handovers—it’s about continually improving the outcomes for the team and business. 

At least, that’s what I hope for you and your team. Unfortunately, some people struggle to care about what happens outside their silo. What about them?

Square pegs versus round holes

We’re all familiar with the square pegs of the development world. They may be brilliant—although often less so than they believe—but they can’t (or won’t) get with the program.

Whether in nature or digital development, lone wolves rarely survive.

Whether in nature or digital development, lone wolves rarely survive.

Our job, of course, is to help them as much as we can. Mentoring. Clear processes. Warnings when appropriate. If that works, great. If not, we need to consider more radical action.

Great teams are built of great people, great people take ownership of the whole as well as the specific.

It’s often said that one brilliant developer is worth ten mediocre ones, but honestly, I’ve seen it go either way. Brilliance can sometimes struggle to see that there might be a better way, or that someone else might have a useful idea.

I have and want brilliant people in my team, but ownership and teamwork are a baseline if you want to build an accelerated digital delivery practice.

If someone can’t work that way, they are going to be better and happier somewhere else. And so will we.

Actionable steps that strengthen a culture of ownership

Before we finish, let’s just review the actionable steps I take when I’m working with a team that’s struggling with ownership. Here’s a roadmap to turn things around:

1. Name the person with overall responsibility for the final project outcome
   This will be your project lead… the specific person who aligns the team and oversees the steps below.

2. Define the process
   Break your delivery pipeline into clear stages (e.g., Design → Design Handover → Development etc).

3. Assign responsibility for each stage
   Make it clear who owns each step in the process. Define at what point ownership transitions.

4. Create explicit checklists
   Include detailed criteria for what “done” looks like at each stage. Automate these checklists where possible—for example, adding them to your cards on a Trello board.

5. Set Work-in-Progress (WIP) limits
   Avoid overburdening team members by limiting how much work can be in progress at once.

6. Mentor and monitor
   Use the process itself as a tool to mentor team members, showing them how to improve their delivery approach.

Start with yourself

There’s one last thing to talk about, and it’s our responsibility.

If you paused on step 4 above, setting Work-In-Progress limits, you’ll have noticed that it was new to the article. I’d be shirking my responsibility to you if I didn’t touch on that in greater detail.

While it’s lovely to get caught up in fantasies of everyone caring about everyone else and pulling in the same direction, it’s useful to remember that we are all human.

It’s hard to care about anyone else when we are buried under work and stress.

The biggest threat to ownership—and accelerated delivery in general—is too much work in progress. Lean manufacturing has a word for this, Muri, that’s usually translated as “overburden”. Put simply, when there’s too much to do, shortcuts get taken, critical steps get missed, and systems fall apart.

If we want our teams to take ownership seriously, we need to give them the time and space to do it. That’s easy to type in an article of course, but is infinitely harder to do.

What I can confirm, while nursing the scars of long experience, is that the universe will happily reinforce whatever path you choose (or are forced) to take. Too much work will lead to stress, mistakes, and siloed-behaviour as people seek to protect themselves. Rework and missed deadlines will mean more work but less progress.

By contrast, doing less work promotes ownership, teamwork, and adherence to processes that will accelerate your digital delivery.  

If we want others to take wider ownership for the results of the team and business, it’s up to us to take the first step.

Bonus: See us chat about Ownership

Why Clarity is Critical for Accelerated Digital Delivery

True story.

I’m in my office. It’s 10AM Friday, and I’m banging my head against my laptop.

(That’s a metaphor, but it might become true any second now.)

In two days, we’re supposed to push an update live for a major retail client. I’m not running the project, but I’m checking the Kanban board to confirm we’re ready. Go? No go?

And we’re not ready. Not nearly.

The UAT column still has cards on it. Not one, or two, or even ten. Ninety-five unaccepted cards.

I need to talk to the team. Now.

I count to ten… get as far as three… then reach for Slack.

---

From pictures to processes

In the last article, we looked at how visibility accelerates digital delivery. Here’s the crux of it:

Visibility is about making it easy for others to see where we are—by which I mean our status, our work, and our overall progress. When we do this as a team, a lot of good things happen.

Although visibility is (sorry, I can’t help this) easy to see, it’s only ever a snapshot of a moment in time. It’s a picture of the process, not the process itself.

And herein lies the danger.

In almost every business conversation I have (or article I write), I touch on the importance of process. It’s process that drives work through the system. It’s process that governs how fast, efficiently, and accurately we deliver.

But “process” is not a principle. Every team I’ve worked in, whether world-class or amateur-hour, has followed some form of process. Some were friction-free and wonderful; others were the digital equivalent of working with the Sheriff of Nottingham. 

(“Locksley! I'm gonna cut your heart out with a spoon!”)

If great processes drive great results, what drives great processes?

---

10:17AM

I’m talking to two developers on the project. Their response to the 95 cards is a helpless shrug of their shoulders. They did their job by getting their cards to UAT. What happens next isn’t their responsibility.

They're not wrong, but neither is this helping us get back on track. The guy responsible for UAT isn’t in today, but he knew about the deadline. We need to push the update on Sunday because that’s when our client’s (300) retail stores are actually closed.

If we miss this window, we miss a whole week.

Here’s the thing. I trust the team. It doesn’t make sense that they would leave without mentioning 95 untested cards.

Which means that I no longer trust what I’m seeing on the Kanban board. Should we be testing all of these cards? Some of them? None of them?

We have a huge amount of visibility… but zero clarity.

---

Clarity (and the three questions that matter)

Clarity is a critical principle in accelerated digital delivery. If you’ve worked in or with an outstanding team, you’ll know that that can always answer three key questions:

• What needs to be done next?

• How should it be done?

• Who is responsible for doing it?

If you think this sounds simple, you’re right, but it’s also rare, especially end-to-end across a process.

That’s why written processes—checklists and Standard Operating Procedures—can be so valuable. They separate the signal from the noise, lessening our reliance on snatched conversations or half-remembered meetings.

Instead, we have clear, functional steps that relentlessly move our project forward. 

---

10:37AM

I’m getting ready to do something I hate—reaching out to people who should be enjoying a day off.

At the moment, I trust each of them far more than I trust the Kanban board. I’m hoping that the cards are actually done, but are sitting in the wrong column.

In other words, I’m hoping that this is a handover problem… a process problem.

And the irony of that hope isn’t lost on me.

None of these people are responsible for our process. I’m the leader. That’s my job.

I send the message.

---

Focusing clarity where it matters most

World-class businesses are highly functional, creating massive value for their clients or customers.

If your team can answer “the three questions that matter” at every stage, work flows quickly through the system. When they can’t, it stalls, goes missing, gets done twice, or (often worst of all) done poorly. I have a special loathing in my darkest heart for work that needs to be redone. That wrecks project plans, budgets, and confidence in equal measure.

And although the principle of clarity is simple, the reality is that it takes a lot of work—especially if we are talking about complex work like digital development.

In practice, it can help us start if we focus on a few high-risk areas. Here they are:

Meetings

There’s a blizzard of advice on effective meetings, but to my simple mind, it comes down to three things:

•  Know what you need to resolve.

• Get the right people in the “room.”

• Document the decisions, actions, and responsibilities.

That’s it.

Handovers

The gap between one person putting a “project” down and another picking it up may be the single biggest risk to accelerated delivery. A customer mindset is critical here. If the UAT Team (to take a random example) is the developer's “customer,” what should the developer provide? What does the UAT team need to successfully execute their work—every single time? Again, this is simple stuff, but standardising how work gets transferred has saved our team thousands of hours.

Feedback

Many of us suck at giving effective feedback. The gold standard is, of course, fast, specific, and honest. Often, though, what we get is slow, vague, and obfuscating.

It should go without saying that brutal or overly personal feedback rarely helps anyone, but neither does sugar-coating the truth. Great people value good feedback because they want to get better. Make feedback sessions into conversations that produce clear, specific, and documented steps forward. That’s the (functional) reason we’re doing it.

Problems

Things go wrong. Mistakes are made. Clients change their minds (then change them back). That’s life. Problems are rarely a disaster in digital development, but our response can often be the difference between starting to fix things right away or spiraling further downhill.

Here’s the critical thing to remember: The moment of guilt, panic, or frustration after you or a teammate makes a mistake is the moment you’re at the greatest risk of making another. One problem is rarely a disaster, but three or four compounded together are what sinks ships, downs planes, and gets contracts cancelled.

Create a clear process for reporting problems, with explicit protections for the team member reporting the issue. We don’t want people hiding mistakes, we want to know about them and get them fixed. Four questions are useful here to get clarity and move forward:

• What happened?

• Why?

• What do we need to do to fix it?

• How can we prevent it from happening again?

Also—don’t leave struggling teammates in some asynchronous Slack channel waiting for the occasional sad crumb of advice. Jump on a call and actually help them.

---

10:47AM

My phone shivers on the desk in front of me.

It’s Slack—one of our UAT team responding to my questions. A quick message, but more than I have any right to expect on their day off.

I read it; then I reread it to ensure I’m getting it correctly. There’s some confusion in the message, a touch of surprise… but fundamentally it sounds like we’re okay.

The client’s UAT team has already signed off on ninety-three of the cards; the other two are last-minute bugs being worked on today.

The code will ship on Sunday.

“Okay”, I think. “Okay, fine.”

But it’s not fine yet. This was forty minutes of raised blood pressure and low productivity. I still don’t know why ninety-three cards were in the wrong place, or why the reason wasn’t captured and communicated.

There’s no clarity yet, but there will be.

And once I understand the issue, I’ll fix it with clear, functional communication because that’s how we roll. 

In my head—at this moment—I’m a rock star.

Springsteen at Madison Square Garden. 

The Beatles busking on that roof.

And weirdly, because I’m a process nerd, I’m starting to enjoy myself.

---

Building a culture of clarity

Over the next few weeks and months, I plan to write and record specific articles and videos to demonstrate how we deliver clarity in practice—but mostly, this is simple stuff.

• A standard meeting template (with someone responsible for filling it in.)

• A Trello card checklist that must be completed before a handover.

• A clear process for capturing problems (and their solutions).

Clarity may be simple as a principle, but it’s still work. Not just to create the assets you need, but to use them enough that they become second nature to you and your team.

At first glance, functional communication can feel humourless and restraining, but in my experience the opposite is true. Teams that adopt this principle have more fun, less stress, and do better work.

Clarity makes hard work easier. When we do it right, we learn to trust the system and each other. When we don’t, digital development is like trying to do open-heart surgery… with a spoon.

---

Bonus: Watch us discuss clarity

Why visibility is crucial to efficient digital delivery

There’s a secret to accelerated digital delivery that I haven’t discussed much… mostly because it feels too dumb to say out loud.

Here it is: Avoid making big mistakes.

As I said, it sounds dumb… but hear me out. In software development—as in anything—there are two ways to solve problems. As a kid, I learned the “fix it” mindset. When something goes wrong, you do something to solve it—a post-problem remedy of some kind.

I think of post-problem fixes as an old-style manufacturing solution. If a car leaving the production line fails its final inspection, it gets shunted into the “finishing shop”. It may need something as simple as a respray, or it may need stripping back down to the engine.

Either way, there’s going to be a delay, and other “mistakes” are piled up ahead and behind it.

Does any of this sound familiar?

Speaking as someone who witnessed (and caused) a decent number of mistakes in the early part of my career, I believe that struggling projects often replicate this sad story: 

A mistake is caught late, delays production, and must be rectified as quickly as possible because it’s causing knock-on issues with other work.

As I said, avoiding big mistakes is a huge part of bringing your project in on time and budget.  

The question is… how?

In the last article, I wrote about accelerators—reusable components we deploy with 100% confidence. They are a huge help in avoiding mistakes.

But accelerators can’t do it all. Every project involves bespoke thinking, unique design, and custom code. That’s how we solve our clients’ problems. And I love it. Solving unique problems is just about my favourite thing. 

But it’s also where we are most at risk of making a costly mistake, hitting a brick wall, or heading off on a wild goose chase.

To mitigate those risks, we need a different tool from the toolkit. We need to build Visibility into every part of our process.

What is visibility in digital development?

Visibility is about making it easy for everyone to see the wood for the trees. Making it easy for others to see where we are—by which I mean our status, our work, and our overall progress. When we do this as a team a lot of good things happen.

• Status: Is a teammate “at work,” either remotely or at their desk? Are they available, in a meeting, or “asking” not to be disturbed?

• Work: What are they focused on right now?

• Progress: Is their work on schedule, ahead, or falling behind?

Later in the article, I’ll discuss practical ways to ensure visibility, but for now, let’s just focus on the practical benefits.

Visibility Benefit 1:
Mistakes surface early

The earlier we can see a problem, the less chance it has to derail us.

This is not a new idea. The aging car lines mentioned above have long since been replaced by lean manufacturing processes. When a modern Toyota worker spots a problem there’s no waiting or shunting the car off the line, they pull a cord that lights up a big board and gets people moving.

If the problem isn’t resolved within a short time, the whole production line stops. You can see this concept—Jidoka—in the following video:

Problems are resolved right on the line—before they infect multiple vehicles.

Digital development isn’t manufacturing, but we can still benefit from fast problem resolution. But we can’t solve them unless we can see them.

Visibility Benefit 2:
Course corrections happen faster

How often have you done a ton of work only to find that it wasn’t what the client wanted? Like, at all?

I’ve seen this happen with design work, feature development, and even proposal writing. Somewhere between you and the client, the brief got garbled (I’m being kind) and the wrong end of the stick was grabbed and run with.

And it’s not just with clients. As a young project leader, I had team members cheerfully nod at my requests and disappear to do the work. Later on—sometimes days or weeks later on—I’d check on their progress only to discover that they’d completely misunderstood.

(Or had they? As we know… clarity is now one of my key principles for accelerated digital delivery. Perhaps there’s a good reason for that!)

In any case, working on a tangent is another reason why keeping work visible—whether for ourselves or our clients—can save a lot of pain.

If we can check in with each other easily and often, course correction becomes a lot easier.

Visibility Benefit 3:
Smoother resource  allocation 

If one of the team is struggling with a piece of work, either its scope or its volume, I want to know as soon as possible.

If they need advice, we can give it. If they need support, they can have it. If the piece of work needs more bodies, we can get them.

Visibility Benefit 4:
Consistency increases

I’ve known people who deny it, but I believe that visibility taps into a basic truth of human psychology: We behave differently when other people are watching.

The degree of difference may vary from person to person, but broadly speaking, we are designed to care about the opinions of those around us.

This can be extremely useful when we are running a team.

In the Accelerators article, I talked about the huge practical value of checklists and processes. I stand by that, but I also know how many development teams have tried to create standard operating procedures, only to find their use degrade over time… and lead to mistakes and delays.

I feel your pain, so let me suggest that making everyone’s work visible is a big step in the right direction.

When our work is truly available to those around us, when we are working on shared documents (or even shared code), we are far more likely to follow a standard.

And—providing the standard is genuinely good—everyone benefits.

How to make your work visible

As you’ll have noticed, we’re really talking about three directions of visibility here:

1. Our teammates need to know who’s working, and on what.

2. Leaders need to track project progress so that they can deliver support when it’s needed. 

3. Clients need to see that the project is delivering. Regular updates reduce surprises and keep them feeling included in the project’s journey.

The way we deliver visibility will change depending on the audience, but building visibility doesn’t have to be complicated. Here are a few tools and setups that make a difference:

• Availability indicators: Simple tools like Slack status lights signal availability. Remote teams don’t have the benefit of in-office cues, so setting statuses to show availability is essential.

• Scheduled rituals: Remote or not, structured visibility practices like daily standups, weekly updates, project demos, or “show and tell” sessions with stakeholders go a long way to keeping everyone informed.
  For clients, weekly sessions to share what’s been achieved and what’s planned help clients feel engaged without micromanaging every step.

• Shared Tools: Tools like Figma for design or shared project boards in Trello allow the whole team to see and comment on work in real time.
  
  Although some might hesitate, giving clients access to tools like Figma or Miro can streamline feedback and keep alignment on track. Yes, there’s a chance of over-commenting, but more often than not, this access just encourages valuable feedback early on.

• Detailed project tracking on Kanban Boards:  Forget the Backlog/Doing/Done approach, use systems like Trello or Monday.com to represent each stage of development.
  Makes it easy for anyone to see where each task stands. Moving a card along the board is simpler and clearer than updating each card’s status individually.

• Use progress indicators: Many of the tools we use can send out automatic updates when work progresses to the next stages. For example, switching design screens to dev mode in Figma can alert the dev team in Slack, or build processes can send status emails.

All of these ideas can be useful, but—as with any technology—leaders must find the balance between what helps… and what hurts…

Side note: Too much visibility leads to obscurity

We all know the frustration of being copied into endless emails, invited to pointless meetings, or becoming blind to apps that notify us about every little thing.

Sometimes this is because the defaults are just wrong, sometimes it’s about people covering their posteriors… and sometimes it's a sign that our teams lack the confidence (or autonomy) to make their own decisions.

These are all good topics for future articles, but the result is the same.

Too much visibility creates noise.

In my last article, I mentioned the value of setting “smart defaults.” The keyword here is “smart.” Getting visibility right is not about blindly following my advice—or anyone's—it’s about doing what works for your team.

If in doubt, start slow and ask for feedback. It’s okay not to know everything, which leads me to…

The biggest benefit of visibility

As I type these words, I’m feeling on edge.

Soon, I’ll share the first draft of this article with smart people I trust… people who know me well enough not to spare my feelings. So naturally, I’m filled with doubt. Not about the ideas, about the way I’m expressing them. Is the article poorly written? Is it obvious? Is it boring?

Visibility requires vulnerability. Putting your work out there, whether it’s an article, a design, or a piece of code, can feel exposing, especially if things aren’t going well. But if you and your team can learn to live with vulnerability, there’s a huge prize to be won.

When we are open and transparent, others find it easier to be the same with you. The best teams I’ve worked with all share this trait—everyone cares more about being good than being “right.”

There’s a ton of power in saying simple things like “I don’t know,” “What do you think?” or “I need help.” Once you get comfortable with vulnerability, you create a virtuous circle:

• Team mates are more likely to raise issues early, which means…

• Problems and challenges surface sooner, which means…

• Mentors and peers have more time to help, which means…

• Issues get fixed faster, which means…

• There’s less stress (and more progress) within the project, which means…

• Team mates are more likely to raise issues early…

And so on.

We’ve all seen the alternatives: Some teams snipe or bicker. Others—and this is often worse—barely talk at all.

If you can see it, you can solve it

Once you’ve seen the value of working with the door open, it’s hard to unsee. Visibility isn’t just about knowing who’s available or what’s been done. It’s about creating an environment where everyone—from team members to clients—feels informed, aligned, and trusted. 

By contrast, low-visibility projects often generate unforced errors, distrust, misunderstandings, wild tangents, and blame (as things go off the rails).

If you’ve spent any time working in digital development, you’ll have likely witnessed some or each of these things.

None of them are fun or productive.

So let’s stand out. By committing to make our work visible, we build a foundation of trust, a currency that keeps projects moving, builds client confidence, and ultimately leads to more successful and stress-free digital delivery.

Start with your own work, then push out from there.

Bonus: Watch us discuss these ideas

Accelerators: The Fastest Way to “Accelerate” Your Digital Delivery

In the previous article, we explored high-level principles that support accelerated digital delivery—Trust, Clarity, Visibility, and Consistency.

These are all well and good, but for principles to mean anything, they have to make a practical positive difference where the work is done.  (We all know companies that preach one thing but do another, just as we know “principles” that buckle and fail under the pressure of reality.)

So how do we bring a principle—say consistency—to bear on actual work?

I’m glad you asked. 

In this article, I want to zoom way in and show you how we embody the principle of consistency in our development processes.

The method is what we call “Accelerators”... but before we get into those, let’s touch on a problem I see in a lot of development teams (and myself).

Why shiny things can kill your business (my precious)

Humans are wired to pay attention to anything new, but I often feel that developers got a double dose of the shiny distraction gene.

Developers LOVE a new shiny thing—especially if it’s a tool or process.

But this is a big reason why we (and our digital development projects) are so often derailed.

I’ve seen this too many times to count in my career. A development team makes a rational and sensible decision to try something new. The new thing—whatever it is—promises a better result in some meaningful way.

And for a while, it seems to deliver.

But then, problems arise that are both unexpected and inevitable.

Because we don’t know what we don’t know.

In psychology, this is related to the Dunning-Kruger Effect, the (much argued over) idea that humans tend to overestimate their abilities when outside their specific areas of expertise.

I can’t speak to the science, but I know from experience that when I’m faced with something new, I often lack the expertise to recognise my… lack of expertise.

The same is true for development teams who try something new and exciting. Here’s how the cycle plays out in digital delivery:

• When starting something new, your team feels highly confident. The project looks simple at first, fueled by incomplete but compelling online examples. Overconfidence reigns.

• Reality sets in. The task, tool, or system is more complex than initially thought. Unexpected problems and delays arise. Confidence plummets and progress grinds to a crawl.

• Slowly, as they hack away at the problem, the team starts to figure things out. They gain efficiency as they become more familiar with the new tool or system.

• Eventually, after mastering the tools and processes, the team reaches the point where they can make accurate predictions and deliver reliably.

Although I’ve exaggerated the cycle for effect, my guess is that many of you will recognise the stages above in some form. Initial overconfidence leads to disillusionment and, finally, a hard-won victory—but only after losing precious time.

This cycle explains why shiny new things can be so disruptive. 

If we aren’t careful, we end up constantly reinventing the wheel… endlessly revisiting stages one and two.

Zero consistency. Maximum stress.

Not to mention unpredictable timelines and unhappy clients.

So what’s the alternative? How can we set up camp in stage four and live there?

Our answer: Accelerators.

What is an Accelerator?

An Accelerator is anything that allows us to work faster, more consistently, or more reliably. It might be a process, a piece of code, a design pattern, or even a piece of infrastructure. 

An accelerator can be something as simple as a consistent folder structure in your Knowledge Management System, or as complex as a full design system (complete with tokens). 

The key thing is this: Accelerators can be reused across multiple projects.

When we create accelerators, we are codifying our expertise, reducing complexity, and setting smart defaults for ourselves.

We are making our work (and lives) consistently easier.

Ten practical examples of Accelerators at work

Let’s look at some practical examples of Accelerators—big and small—culled from our team.

1. The two-character email address

When I need to type my email address out, I use a two-character code (,e) to trigger a snippet in Alfred.

2. Our Project Delivery checklist

Checklists can accelerate progress by reducing the mental load on your team and ensuring that nothing is overlooked. (If you’ve not read Atul Gawande’s book, The Checklist Manifesto, we highly recommend it.)

Here’s the simple checklist we use to sanity-check whether we should start a new project.

3. Easy email templates embedded in our workflow 

Using Google Docs to write articles makes it easy to embed email templates within our workflow. Once the second draft is done, for example, we send a standard email to our outside reviewers to get feedback. A single click opens an email with the recipients and content prefilled. Paste the link, hit send, and you're done. 

4. A consistent folder structure across all platforms

I loved the practical simplicity behind Tiago Forte’s book,  The PARA Method. Forte argues that we can organise our work, thinking, and lives into four categories: Projects, Areas, Resources, and Archives.

In a world where information is often spread across multiple platforms, having a common structure can hugely increase the speed at which things can be found.

5. Template cards on Trello

Templates allow us to build smart defaults into our systems, releasing us from busy work we must do every time (and avoiding the chance that we’ll miss something important).

6. An “accelerated” desktop

If you know the French phrase, “Mise en place,” (putting in place) you’ll understand how seriously professional chefs take the idea of smart defaults. They know that their best work requires every tool and ingredient to be where they expect it to be at the start of service.

Our Content Strategist uses this one-click shortcut (in Keyboard Maestro) to reset his desktop at the start of every session, arranging apps and Chrome tab groups into specific places… because knowing exactly where things are is a huge accelerator.

7. Our design system in Figma

Figma allows us to reuse our design patterns, literally embedding our expertise and experience into the interactions and code.

8. The standard process we follow to deliver client projects

9. The document we fill out after the Discovery Sprint

Every delivery begins with a Proposition Brief, a standard document that puts us and the client on the same page… literally and metaphorically.

10. And a bonus…

Naturally, as we’ve just started writing articles, we have an article template set up in Google Docs. This will develop over time, but its early existence speaks to something more important than any individual example… our Accelerated mindset.

Building an Accelerated-mindset

It’s probable that none of the examples above surprised you. If you work as a developer, I certainly hope that you already have a documented process, use tools like Figma, and develop reusable code.

If you don’t, start there. (I’ll be writing articles that cover each of these things.)

But assuming you do any or all of the above, I’d like to invite you to think bigger. Reusing email validation code is one thing, but what if we could lift and reuse whole sequences?

Here’s an overview of a login sequence we have reused in numerous apps.

What happens when things HAVE to change?

As you’ll have noticed, our examples above include plenty of recent tools and technologies, so let's address an obvious criticism of the argument I’ve been making.

Yes. Sometimes we have to learn new things. And sometimes, the pain of change will be totally worth it. The question is… when do you want to feel that pain?

I’ll tell you when you shouldn’t want to feel it—when you are working on a client project.

That’s why we never (ever) experiment on Customer Code.

Instead, we rely on our code library, design system, and interaction guides. These tools are built from cumulative knowledge across numerous projects, allowing us to deliver quickly, reliably, and confidently every time.

Accelerators will give you the confidence to move fast without breaking things. That’s what we’re paid for. That’s what builds our business.

And because we can deliver so quickly and efficiently for clients, we have the time to experiment (on non-client) code when the business case arises.

Conclusion: The four BIG benefits of Accelerators

In today’s development landscape, every moment counts. As my friend Don Norman says: “The moment you start a project, you are already behind schedule and over budget”. 

Accelerators don't just speed things up—they improve quality and predictability through:

• Speed: By starting with known, stable assets, you avoid the time sink of creating infrastructure from scratch. For instance, a one-click authentication system can save hours, if not days, of development work.

• Predictability: With accelerators, you know exactly how long tasks will take because you’ve done them before. This predictability is invaluable when creating timelines and managing client expectations.

• Cost-Efficiency: Time saved is money saved. By accelerating the delivery process, you reduce the cost of production and boost profitability per project.

And here’s the final benefit. If you allow accelerators to handle the repetitive tasks, you free yourself and your team to focus on what truly matters—the innovation required to make each specific project the best it could possibly be.

Trust me. Consistent, stress-free delivery is the shiniest thing of all.

Still struggling to deliver apps or digital products on time? Here are the four principles that underpin our success.

Why is digital product development still so hard?

Over the past 20 years, I’ve worked in dozens of development teams and connected with hundreds of developers. By and large, they were smart, motivated people trying their best to deliver high-quality work on time and budget. 

And yet… if you’ve been a product owner or team leader, you’ll likely know the pain and suffering of digital delivery.

Patchy progress. Missed deadlines. Broken features. High-team turnover. Amateur mistakes and misunderstandings. Unchecked feature creep. Stressful meetings. Angry clients. Knock-on effects that (arrggg) force the next project onto the back foot.

Many of these frustrations are burned into developers like a brand… along with sleepless nights and ego depletion. In more extreme cases, entire careers are impacted, not to mention the clients and businesses that rely on the work.

It shouldn’t be this way. We have Lean, Agile, Scrum, Kanban, and hybrid methodologies of every hue. We have tools and processes that our technical forebears could only have dreamt of.

So why does digital product development still feel like juggling smoke?

My answer… and I say this as a 20-year veteran, is that effective digital delivery doesn’t start with tools and methodologies.

At UX Consultancy and Creation On Demand, we’ve built our reputation on four simple principles. There’s nothing radical about them except that they just work. Whether you are an in-house department or a remote team like us, they’ll help you accelerate digital delivery.

But before we look at them, let’s answer an obvious question.

---

Why put principles before processes?

Why principles first? Because they streamline and simplify most of my decision-making. In a market constantly offering new and shiny ideas, principles keep us focused on the fundamentals.

If that new tool or process isn’t helping you do the work that matters most, it shouldn’t matter how shiny it is.

Our principles save time, but be warned—there are no magic bullets here. Nothing I’m about to reveal will stun or surprise you. If anything, your reaction will be muted disappointment. Of course, you’ll think. I know this. Why are you wasting my time, Matt? I’ve got piles of unread emails…

And you’ll be tempted to move to your next internet snack.

But that would be a mistake.

Knowing is not the same as doing. Although you’ll recognize the principles below, the likelihood that you have truly and genuinely internalised them is far smaller. Few development teams have.

As with much of life… it’s not the ideas that matter; it’s the discipline and commitment to follow them through.

---

The four principles we built our house on

In future articles, I’ll explain how we inject these principles into our day-to-day work, but for now, I want to focus on the basics.

Principle 1: Trust

Trust is the single biggest accelerator in our business—perhaps any business. Trust between teammates. Trust between partners. Trust between agencies and their clients. 

Nothing is more important, but there are a couple of real challenges here.

First, you can’t just go out and get some trust. It’s like happiness, a side-effect of other things. This is apparent from our in-house playbook, which lists ten trust-building practices:

1. Valuing long-term relationships. We are in business for the long term and act accordingly.

2. Honesty. We always tell the truth, even if it’s awkward.

3. Honouring our commitments: When we make a promise, we follow through.

4. Admitting when we’re wrong. When we make a mistake, we own it.

5. Clear communication. We are precise in our speech and writing. If we aren’t sure about something, we ask for clarification.

6. Being helpful. Without agenda, we strive to be helpful to our customers and colleagues.

7. Caring. We show we care by being interested in other people. Remembering the little details goes a long way. 

8. Standing up for what’s right. We won’t sacrifice our values for what’s quick and easy (see 1).

9. Transparency. We explain what we’re doing and why—and gladly share our expertise.

10. Being vulnerable. We aren’t superhuman. Sharing our problems or fears isn’t a weakness; it’s a strength—especially when we all help each other.

Working in this way inevitably builds trust, both within the team and with our clients. The practices are simple, but simple is not the same as easy. I’ve worked in enough teams to understand how easy it can be to make a mistake.

• The “white lie” about timings for a stalled project.

• The rushed email that sacrifices accuracy for speed.

• The pressure to “work through the night” (that precedes the inevitable burnout).

Trust is valuable precisely because it is so hard to create. That’s why our three remaining principles are designed to help us earn and deserve it.

Principle 2: Clarity

Although we touched on communication above, Clarity is critical enough to be its own principle. I’ve seen more projects fail due to poor communication than anything else:

• Bad RFPs waste everyone’s time.

• Poor proposals lose bids… or win them (which is often worse)!

• Hurried emails cause confusion.

• Poor mockups require questions and revisions.

• Hiding issues—or ass-covering—wastes everyone’s time.

In future articles, I’ll detail how we build clarity into our tools and processes, but for now, here are the simple guidelines we follow:

• We pay attention to the details.

• We ask clarifying questions.

• We finish our conversations only when we are sure everyone understands.

• We document our meetings.

• We ensure our project documentation is consistent.

The goal here is simple… for everyone to understand exactly what’s been agreed, their role within the project, what’s expected of them, and when.

Again, simple isn’t always the same as easy, but taking the time to be clear avoids all manner of self-inflicted wounds.

Let’s look at another way to make life easier…

Principle 3: Visibility

Digital product development can feel like an iceberg, with 90% of the effort hidden from view on hard drives or cloud servers. If you run a remote team, as we do, it can be harder still to know what’s going on.

And that’s an issue because effective development requires visibility—of people, progress, and problems. As a product owner or team leader, I need to be able to take a quick look around my (virtual) room and see the status of the project. Is everything where I expect it to be? Is something falling behind? Does someone need help?

The gold standard is this: No surprises.

Visibility of progress gives you and the client confidence. But if you can’t have that—we all work in the real world, after all—the next best thing is an early warning if there’s an issue. High visibility of people and their work allows us to course correct when snags occur.

There are numerous ways to increase visibility, from standups to kanban boards. We’ll cover many of these methods in future articles, but at a basic level, we have our team members follow these guidelines.

While working, we will:

• Be present and visible to our colleagues (whether in the room or on Slack).

• Let teammates know if we’re unavailable: in a meeting, on focus time, at lunch, etc.

• Check in often, ensuring that our tasks are properly tracked.

• Attend meetings on time and be ready to focus.

• Surface issues or questions as soon as they arise—no waiting.

Principle 4: Consistency

To state the obvious, it’s no good doing a great job once.

Great teams don’t just deliver; they deliver every time. Day in. Day out. Rain or shine. Relentless performance is a crazy powerful trust generator, and the secret to getting it is really no secret at all.

Consistent teams follow consistent processes, use consistent tools, and act in a (say it with me) consistent way.

It blows my mind that so many companies still develop on an ad-hoc basis. It pains me that so many others do the work to develop a process only to abandon it when things get tough.

I’ll talk about the processes and accelerators we use in future articles, but for now, I want to highlight the critical importance of having a documented way of doing things. For example:

• We don’t develop our wireframes until we know our user stories.

• We don’t map out user stories unless we’ve gone through our Discovery process (step by step) to understand the nuance of what the client is looking for.

True consistency can require real discipline at first, but trust me, it gets easier… and then it becomes your engine of growth.

To be clear, I’m not saying you shouldn’t change or evolve. Quite the opposite. Once you have an agreed standard of work, you have something that can be tested and improved. For example, the process we use to write and publish this article will likely look very different six months from now.

Stick around. Maybe I’ll write an article on it.

---

Putting the pieces together

When you’ve made as many mistakes as I have (and delivered as many projects), it’s hard to ignore the patterns around you—especially this one...

Trust makes every aspect of business easier—and the way to build trust is to consistently and visibly do what you say you are going to do.

See how that works?

There’s nothing radical about our list other than the fact that we live by it, building the principles into our workflows and processes.

But that’s a story for another time.

In the meantime, which of the principles would be easiest for you to improve in your business or team? The first answer is usually clarity or visibility, but your mileage may vary.

---

Bonus: Watch us discuss these ideas

Three +UXC launches Conn3ct

🎉 Big news! We're thrilled to unveil our latest project for Three, Conn3ct! 🚀

Conn3ct is a future thinking #EmployeeExperience platform designed to revolutionize how teams at Three connect and thrive in our ever-evolving world! 🌐🤝

Say goodbye to disconnected teams, and hello to a whole new level of engagement! Conn3ct is more than just an app; it's your team's ultimate companion, seamlessly integrating News, Social features, Recognition, Reward, and real-time notifications. 📰📱✨

Would you like to dive deeper? We'd love to chat with you and explore how our Employee Experience platform can work wonders for your organization.

Let's connect and discuss how we can help you achieve similar amazing results! 📞🌟

100,000 thank yous!

In October 2021, we launched a new Employee Recognition portal for Three called 3Celebrates. It's a tool that allows employees to say thanks and as a way for Three to recognise their employee's milestones.

Since then, we've sent over 100,000 Thank yous, Happy Birthdays and Milestone Celebrations.

UXC are specialists in creating Employee Digital Tools, like 3Celebrates, that help creates an engaged, empowered workforce who communicate, collaborate and deliver business value regardless of location.

Three partners with UXC to build their Retail EmployeeXP App.

Three have selected UXC to design and build a new employee engagement app for their retail staff.

The app will make it easier for retail staff to support their customers by putting all the tools and information they need at their fingertips.

Three chooses UXC to deliver its new recognition system

UXC is very pleased to announce that we have been selected by Three Mobile to provide a brand new system to unify the recognition system between its UK and Ireland operations.

Three select UX Consultancy to deliver their new Intranet

UXC has worked in partnership with Three for the past 6 years to create an employee engagement platform that enables their employees to communicate, collaborate and deliver their business goals regardless of their location. 

We are very excited to continue this work with Three by creating a new best of bread corporate intranet that works seamlessly with their existing employee tools through the employee engagement platform.

Reach TV Selects UX Consultancy to design their new digital streaming platform

UXC is very pleased to announce that we have been selected by Reach TV to design a their new online Digital streaming proposition.

Reach TV’s shares its digital video content to 128 million customers across 1.7k screen in 90 airports across America and is expanding its potential audience with the creation of its new web streaming offering. UXC has been engaged to help ReachTV through a discovery and designs sprint.