‍

In the same way Chapter One became a manifesto for Thankyou, Ask Your Developer is the tech version of Twillio’s company values brought to life. With cues from AWS, ING and Banq, and tangible examples of optimising a business for success, Ask Your Developer is a great read for anyone looking to understand how to foster creativity in a company —  whether you’re working directly with a developer, or not. 

First, a little about me. I’m one month into a new role as Head of Marketing at SaaS company Particular Audience, an e-comm tech business providing world-class search, merch and rec solutions, without the need for cookies or first-party data. I could go into the spiel about using itemized data and AI tech, but I’ll leave that for later.

It’s a company founded on developer innovation, where developers are at the heart of the business, while sales, business development and marketing support the expansion.

So, when the CEO and Founder James Taylor suggested I give Ask Your Developer a read, I thought it would be a great opportunity to share how a marketer can use this book to gain practical insights for implementation. 

During this review, I’ll focus on a few lessons in particular:

1. Focus on the customer;
2. Experiment to innovate;
3. Make every job creative, lead with creativity; and 
4. Share problems, not solutions.
   

Early on in the book, the reader is made acutely aware that Ask Your Developer seems to be less about the developer than how to motivate people and build a business. For this reason, many insights shared in the book are also relevant to a budding marketer wanting to supercharge a tech business. 

Here are some nuggets I learnt along the way. ‍

‍

1. Focus on the customer [page 64]

Whether you’re working with a developer or not, ensure that you link what you’re doing back to how it will help the customer, and ensure everyone in the business understands their purpose. Note: We’re currently doing this at PA through a Salesforce borrowed process of V2MOMs. So this is a very timely reminder.

A practice Jeff Lawson shares in the book is to often ask developers what user problem they are solving for. beyond fixing a bug or optimising experience, for example.
I’ll avoid the Start with Why reference beyond this point. But, being reminded of this was a poignant example to not lose sight of the customer in everything you do. 

‍

2. “Experimentation is the prerequisite to innovation” [page 65]

A developer approaches a problem the way a marketer should [page 12], and the way I am in my new role. 

This framework involves:

1. Listening to your customer;
2. Building an initial solution to a problem;
3. Getting feedback;
4. Iterating; and
5. Improving.

Call it a feedback loop, experimentation or simply the way growth marketers prove incremental improvement or test hypothesis. I love it. And it's how I’m approaching marketing in a startup.

With constraints of limited resources, budget and historical data to guide future strategy, I’ve learnt just how important it is to not be precious when it comes to what I think (thank you Ego is the Enemy) or what I believe to be true when it comes to a customer.

Sure, experience will help shortcut marketing strategy. But this book was a reminder that an unsuccessful experiment is not a failure, it's a learning. And that a lot can be gained from “swinging for the fences”, as Jeff Bezoz calls it. 

Understanding how to utilise resources efficiently is an art I’m still learning.

However, something we can all take from Ask Your Developer is [page 111]: 

“The aim is to test a lot of little ideas to see which one will grow.

First, vet the idea. You want to know: 

• What assumptions about customers, the problem or the market are you making, and how will your experiment prove or disprove the assumptions?
• If you’re wildly successful, will it be a big outcome? 

Next, agree upon metrics for success. 

Then, test with a small amount of budget and then build out.”‍

‍

3. Make every job creative. In other words, lead with creativity‍

Early on, [page 79] we are reminded that when someone is OBSESSED with what they do (whether its growth hacking or the creativity of the process) they will succeed. And, as Jeff says, code is creative.

He shares how developers are creative problem solvers and should be treated as such.

So, for the team at PA, I’ll try and live this in my day to day. Everyone should be treated as a creative problem-solver, which, I’ll admit, seems a little more straightforward when it comes to talking about content or design.

Another work ethos I’ll try to live is the importance of giving responsibility and freedom. Not just in working hours or what to wear, but freedom in terms of creativity [page 79].

From Ask Your Developer [page 104], I learnt Y Combinator does a Request for Startups to get developers to find a creative solution to a problem that the world is facing. I’d love to do the same in marketing.

If we’re completely borrowing the concept, we can ask every one of the 60+ members of PA across five offices to answer a Call for Growth, asking for the craziest growth ideas in every region.

This book is a great reminder of how important it is to encourage creativity and bring people together. As a jaded marketer it's easy to say ‘marketing doesn’t just sit with marketing’, but I don’t think that’s the point.

How can you bring people together to solve for the same solution, while maintaining excitement, avoiding burnout and facilitating growth? I’ll admit, I’m still learning. 

Quote [Page 127]: “Success is stumbling from failure to failure with no loss of enthusiasm.”

‍

4. Share problems, not solutions

‍“I don’t have time to explain it.” “This brief should shortcut discussion around problem/solution.” Or, my favourite, which I mistakenly said to our UI designer recently: “It shouldn’t take that long.”

I may be specialised in some things, but that doesn’t give me, or anyone, the right to say to another specialist “it shouldn’t take too long”.

Ask Your Developer shares a real insight and reminder to every worker on earth. It’s important to share problems, not solutions [page 72].

In the same way I wouldn’t know how to build a website without Squarespace, I shouldn’t be dictating a solution to a UI designer. Instead I should be sharing a problem with insight and giving room for lateral thinking.

Bringing this into PA, we’ve just started a Design Academy, to help our graduate designers better understand the foundations of design and share the tools they need to solve the problem. Not just answer a brief.

For any motivated specialist learning their craft, this is 100x more exciting than spending the day getting brief after brief, with a time schedule and fixed solution.

In primary school I remember learning about the coloured hat theory. This is that in action.

The ‘Ask Your Developer mindset’ is about getting people to work together to hear customers’ needs and answer them. That’s worked pretty well for Twilio. And I think it will work well for me too.

‍