Talking to your customers: a disruptive Agile framework

In this post, I’ll present a robust and disruptive Agile framework. It’s called “talk to your customers” — or, in short, TTYC.

Soon I’ll be selling a 500-page book with enough diagrams to convince you it’s a framework worth trying. If you are interested, you can also contact me for a $50,000 workshop in which I’ll recite platitudes and declaim all the necessary technical terms to make it “enterprise-ready”.

For now, bear with me. This blog post is all I’ve got.

TTYC’s core-workflows

The Talk To Your Customers framework revolves around talking to your customers, an arcane practice long forgotten in the software industry. Here’s a flow chart to help you understand the core workflows of the TTYC framework.

As surprisingly as it may seem, the part about talking to your customers is crucial for TTYC’s success.

TTYC’s roles and core-metrics

TTYC has two roles: the customer and the product developer. The customer is responsible for having problems, and the product developer is responsible for delivering solutions to those problems. In exchange for the solution, the customer will provide the product developer with an artefact called “money”.

Besides building products people want, TTYC also values this “money” artefact instead of story points, cycle-time, and velocity, as other Agile frameworks do.

My experience in the software industry tells me that many may see this abrupt focus shift as a disadvantage, and I understand such complex concepts may turn some folks off. Yet, I firmly believe in this thing called “money”, which tends to be a result of shipping great products.

For the folks who like graphs, here’s an ideal plot of money over time.

See? It’s all very scientific.

As time passes, money should go up, not down. The higher it goes, and the more quickly it goes up, the better.

TIP: If you build something people want, it will naturally go up — providing you can sell.

Putting TTYC into practice

In Talk To Your Customers, the first thing you should do is talk to your customers.

You should get them on a call, or meet them for coffee, and listen to their problems. I know it may sound counter-intuitive, but for this technique to work, you’ll have to actually listen.

When allowed, record these conversations so that you can listen as many times as you need.

If you’ve got a recording, incentivize other team members to listen to it. Yes, that includes the people writing the software. Remember: there’s no “software developer” role in TTYC. There’s only the customer and the product developer.

Here’s why the listening step is crucial: remember what I mentioned about that “money over time metric”? Customers are the ones giving you the money, and it seems they’re more likely to give it to you if the solutions you deliver actually solve their problems. Listening helps you understand the customer’s problems and, in turn, solve them.

Implementing a solution

Once you’ve listened to the customer’s problems comes the most challenging part of TTYC: implementing a solution.

At this stage, TTYC recommends your team think about what the customer wants to accomplish and why. If any questions arise during the process, you should go back to the first step: talking to your customer.

Remember: it’s your job to come up with the solution, not the customer’s. When you go back to ask them questions, ensure you’re not simply asking them to design the solution for you. If they could do that, they’d probably have done it already. If they could have done it but didn’t, it’s because the problem doesn’t matter much.

Once you’ve got a grasp of what the solution might be, you should go and build it. There are only two caveats you need to which you need to pay attention here. The first is that you don’t necessarily need to get the solution right straight away. The second is that building it doesn’t necessarily mean writing the code.

Let me explain those two caveats in more detail.

Getting the solution right

In case you forgot, Talk To Your Customers’ core value is talking to customers, which means you can rely on them to tell you whether the proposed solution works.

Over my many years as a TTYC devotee, I’ve noticed that, for some reason, it’s usually better to ship something and ask the customer whether your solution works than to confabulate among developers in two-hour-long meetings. It may be because the customer is the one driving the “money” metric, but I’m not sure.

In other words, if you’re not sure, ship it, and ship it quickly.

If something doesn’t work, customers will let you know, providing you listen to them. If you follow this approach, you’ll shorten the “time” metric (remember our “money vs time” graph).

Building it

Customers will only provide the “money” artefact if you solve their problems. Notice I didn’t mention “using Kubernetes” or “microservices” anywhere in that phrase. Do you know why? It’s because it doesn’t matter. Notice I didn’t mention code too? That’s because it doesn’t matter either.

If you develop a no-code prototype in an hour and it solves the customer’s problems, they’ll probably give you money for it. If that happened, great! You’ve achieved the goal of increasing the “money” metric and diminishing the “time” it takes to get it.

From here on, you can now choose to scale your solution, improve it, or find other problems to solve.

TIP: Instead of solving imaginary problems, TTYC advocates that you should solve problems that exist or will exist soon.

To summarise: in TTYC, we advocate that building software which solves the customer’s problems is better than building complex software. It may seem absurd, but problem-solving and money are highly correlated — much more highly correlated than money and Kubernetes.

Putting it all together

The TTYC framework focuses on a disruptive concept called “talk to your customers”. Although the framework’s name has “talk” in it, it really means “listening”.

This framework has two roles: the product developer and the customer. The product developer’s goal is to acquire an artefact called “money” and to do so in as little time as possible. The customer’s role is to solve their problem. If the product developer can offer a solution to the customers, they will probably exchange their “money” artefacts for the solution.

The revolutionary aspect of TTYC is acknowledging that solving the customer’s problems is more important than building software or having meetings. Therefore, it advocates that product developers must talk to customers instead of spending hours discussing possible solutions. Furthermore, TTYC incentivizes product developers to ship their solution and ask customers whether it works instead of assuming it does.

Wanna talk?

I currently offer mentorship and consulting packages for individuals and startups wishing to ship more software in less time and with less stress. If you’re interested in improving your processes and pipelines, book a free introduction call here. I’d love to help you solve any problems you might be facing or answer any questions you might have.

Alternatively, you can send me a tweet or DM @thewizardlucas or an email at lucas@lucasfcosta.com.