Things I learned at Local Welcome
My contract at Local Welcome ends at Christmas after two years. It has been a wild ride and I’ve loved every minute.
We took a great idea that Local Welcome had been developing since 2015 - bringing local people and refugees together to cook and eat a meal as a way of building community connections - and scaled it into a national service operating in 8 cities across the UK.
Then the pandemic struck and we had to stop doing our meals. Over the last 6 months we’ve accepted that loss and pivoted to two new services - Local Together and ADHD Together - that aim to have similar outcomes.
I learned some big things about product management at Local Welcome:
I also made some mistakes. I always do. I plan to learn from these in the future:
I’m sad to leave Local Welcome but peaceful because the team’s in a great place to go on without me. I’m looking for a new product role starting in January so drop me an email to myddelton@gmail.com if you’ve got any suggestions!
Now, let’s get into those lessons and mistakes...
Things I learned
Riskiest assumption experiments are my north star
At Local Welcome my role was to take the meals concept that already existed and prove it could be a scalable, sustainable national service. The team had secured funding from the Lottery to do this based on an untested hypothesis that we could operate 100 groups every weekend.
This was an overwhelming challenge until we broke it down into its riskiest assumptions. That we could run groups in places we didn’t live, charge people to come, train leaders who were not our staff, find and turn out refugee guests, have meaningful impacts etc.
Once we listed the riskiest assumptions an obvious sequence of work jumped out. We ran experiments to understand these assumptions one by one. They were not simple pass/fail experiments aimed at some kind of scientific truth. They were design experiments to learn what approaches worked well enough to move onto the next assumption. That’s how we built Local Welcome.
There were trade-offs. This approach worked for exploring the big decisions early on in our product. But it created service debt to fix later as a result of all those ‘good enough’ decisions. I was OK with that because our priority was to prove the viability of the service before our money ran out.
It worked. The Lottery gave us continuation funding in March 2020.
Off-the-shelf software is cheap and crazy powerful
We tried and failed to hire a tech lead when I joined Local Welcome. Actually, we decided not to hire at the last minute because we realised we didn’t know what we needed to build. And tech leads are expensive.
Instead we started with Software-as-a-Service (SaaS) products hosted in the cloud. Hubspot to store all leader and member signups. Eventbrite to sell tickets to meals. Stripe to take monthly subscription payments from leaders. Within a month we were running meals in Cardiff.
We slowly worked out that these products talk to each other. Eventbrite tells Hubspot when people buy tickets or attend a meal. Stripe tells Hubspot when a leader sets up a payment. We started using workflows to automate things - update a leader’s status, send an email, notify us, add people to a list - whenever things happened in Eventbrite or Stripe. And we added more products - Sakari (SMS), Calendly (call booking), HelloSign (signatures), Donorbox (donations).
We still run on this SaaS technical architecture. Small pieces, loosely joined. Simple service design to keep it technically straightforward. Custom error messages to bring the inevitable exceptions to our (human) attention to fix manually.
Again, there were trade-offs. Each product was easy-to-use for our users because they’d each been designed for a single purpose. The loose joins let us swap out Eventbrite for Tito in two days. But our service design was constrained by the capabilities of our tools and in some areas we learned we needed custom software.
Worth it though. We saved more than £100k we would have spent on a tech lead.
Whole-team planning creates shared direction
I’ve seen what happens when you give individuals autonomy in teams without having a shared direction. Brilliant people go off in all directions. Wars break out. Money is wasted. It’s ugly and has scarred me for life.
At Local Welcome I created shared direction using a two-step process:
Phase planning. Every four months we gathered to plan the next four months. We did workshops including a retro, an appraisal of where we were, and an exercise to imagine our future over the next two years. Then we wrote our OKRs for the next four months as a team. We ended with writing a list of epics.
Epic kickoffs. Each epic kickoff lasted two hours with the whole team. The first hour was show and tells so could all start from the same place. The second hour was us each answering five questions - what is this epic, why is it important, when is it done, what is included, what’s not included - and then discussing and arguing these into a single set of answers that defined the epic work.
Planning as a whole team brought things to my attention I’d have missed on my own. Even better, over time I watched people make smarter product decisions in their own post-its. That’s gold for any team.
Of course we had disagreements. When that happened it was me that made the final call when it came to product decisions. I found that having this whole process out in the open forced me to articulate my thinking in ways that made it easier for people to disagree-and-commit. It also meant they could hold me to account when my decision was wrong (which was often, and they did).
Yes, it took more time upfront to take a whole-team approach to planning. But what made our team more than the sum of its parts was that we didn’t just have individual autonomy - we had a shared direction too.
You’re gonna need a bigger goal
When I joined Local Welcome we wrote a two-year goal together. We did this without mentioning meals or refugees because I’d read somewhere that your goal shouldn’t tie you to an operating hypothesis.
We came up with “operate an impactful, inclusive ritual that is membership-funded”:
“Operate” because it wasn’t enough to just design a thing.
“Impactful” because it had to improve people’s lives.
“Inclusive” because we wanted diverse, powerful communities.
“Ritual” because attention, intention and repetition bind people.
“Membership-funded” because we couldn’t rely on funders forever.
For the first 18 months it felt like we didn’t need an abstract two-year goal to guide us. We were doing Local Welcome meals!
Until the Covid-19 pandemic happened and we had to stop doing meals.
In the darkness we turned to our two year goal. We imagined new services. We kept asking - what is the ritual, how is this inclusive, why will people pay for it, what impact will it have, and how will our team operate it?
Our two year goal helped us pivot to Local Together and ADHD Together.
User research with real signups is my jam
At GDS I worked as a user researcher on GOV.UK Notify. Our users were government services. No recruitment agency could find participants and we couldn’t pay incentives. This was a big shock for the design agency researcher in me!
We improvised. When people signed up we offered a fair exchange - give us an hour and we’ll give you free early access. We got amazing research outcomes because our participants were already in the headspace of using the service. We didn’t have to manufacture hypothetical use cases.
I brought this approach wholesale to Local Welcome.
When someone signed up we arranged a phone call. We asked how they found out about us, what they thought our service was, why they wanted to get involved, and what concerns they had. In return we explained things in detail, answered their questions, and gave them early access to our tickets.
This helped us fix concerns and problems. It kept our team grounded because we all did calls. It built trust among our potential leaders.
When we launched Local Together and ADHD Together we started with Facebook ads and bare-bones propositions. We asked signups about their motivations, expectations and concerns. By the time we started running events our rituals were already designed in harmony with users’ needs.
Doing this kind of intercept research with signups is a powerful tool for developing new products. I’m amazed how little it gets talked about.
People respond best to real people
One of the first things I asked our designer to do at Local Welcome was to create a branded email template. Logo, brand, sent from “Local Welcome team", even some cute GIFs of puppies.
We don’t use that template any more. Now we send plain text emails from our personal email addresses. Even for automated emails.
We learned that people (and spam filters) respond best to regular emails from regular people. They do things like open them, read them, and reply to them. And they just love to send angry emails when things go wrong.
Yes, it was hard to receive random angry emails. But it showed us where things were going wrong. And it gave us the chance to reverse the anger into loyalty with a proper apology. We said sorry, owned any pain we caused, avoided lame excuses, and explained what we’d do to resolve things.
In January I started sending a monthly email to 150+ leaders to let them know what we were working on. It was a risk to expose them to our agile methods. But treat adults like adults and they respond like adults.
I know. Not possible at scale. But very useful when you’re starting out.
Written culture makes things resilient
At Local Welcome we worked in a lean and agile way which meant lots of knowledge was in our heads. This was great for rapidly iterating a new service. But not so great when people started forgetting things, taking holidays, or leaving. Knowledge kept walking out the door.
Our antidote to knowledge loss was a written culture. We used Notion for this, which Ella - one of our trustees - describes like this:
“It's the beautiful love child of a website and a kanban board, mixed with the prettiest of all WYSIWYG blogging platforms you can imagine. With the efficiency of Google Docs. Basically, the Beyonce of software.”
We used Notion for three critical parts of our written culture:
Meeting notes. Every time we met as a team someone took notes in Notion. We did pretty much verbatim notes because it was easier than doing live-filtering. We created and followed an agenda. We captured actions as we went. This saved us a million times.
Operational processes. We had a mix of automated processes and manual operations. We documented our manual operations so that we didn’t forget them and so other people could do them for us.
Epics. After phase planning we listed epics as cards. After kickoffs we added definitions to the cards. As we worked we stored notes inside cards and tracked progress on to do lists.
Listen to me talking about our written culture on the Cherryleaf podcast to learn more.
We were way more resilient with our strong written culture. It also made it easier to switch to remote working during the pandemic.
The runway won’t take care of itself
Local Welcome is not a big organisation. We had money in the bank and when it ran out we would cease to exist. Product growth costs money (hiring staff, opening groups) and makes money (tickets, donations). Understanding the impact of growth was my responsibility.
We built an agile forecasting tool to help. A massive spreadsheet where:
Every column was a month stretching away off the right-hand side into the future. We looked two to three years ahead.
Every row was an expense row (staff costs, overheads, group costs) or an income row (funding, member income, donations).
Each expense/income row had a corresponding separate tab with a detailed model appropriate to the context (that fed the row).
The final row started with the cash in our bank and showed how that changed each month according to the modelled future.
This agile forecasting tool had several uses for us:
Showed when our cash ran out (cashflow runway) and our funding ran out (funding runway). These were not always the same.
Provided a tool for leadership to review actual against estimated spend each month to make sure our modelling wasn’t off track.
Let us model changes to staff, overheads, growth, tickets, group costs, donations etc to see their impact on our runway.
Helped us respond to the inevitable changes from operating in a lean and agile way by giving an always-up-to-date forecast.
Made it easier to communicate with the trustees who scrutinised our finances and understood the impact of our changing plans.
Our agile forecasting tool was put to the test when we came within six weeks of running out of money in March 2020. We saw this coming from September and stopped opening groups in December to give ourselves the runway we needed to land our next round of funding.
The one thing we stayed calm about during this stressful time was the accuracy of our agile forecasting tool!
Working with an ADHDer has changed me
Ben, who is the Local Welcome CEO and founder, has Attention Deficit Hyperactivity Disorder (ADHD). He was open about this and shared some of the positive and negative aspects of living with ADHD with me.
I’ve never knowingly worked with anyone with ADHD before. Although seeing as 5-8% of the population have ADHD I think it’s likely that I have.
Ben’s ADHD brain has lots of benefits. It’s faster than mine at connecting topics and seeing patterns stretching into the future. There are lots of advantages to thinking in the way that Ben thinks.
But it causes some difficulties too. I worked with Ben to understand where his ADHD made things harder for him than for others. And we tried out ways of working to minimise the impact of some things:
People with ADHD often lose track of time. Our workplaces are often highly structured around time. We tried to find ways to nudge Ben to note the time when he’s in full flow, not hold him to unrealistic standards of promptness, or simply allow more time for discussions than we think we need because he needs more time.
People with ADHD can struggle to follow step-by-steps. Our workplaces are full of step-by-steps like agendas for meetings. We tried to build patterns into our Notion meetings where the agenda automatically formed the note headings. Our leadership team agenda led us heading by heading and it worked beautifully.
None of these difficulties stopped Ben doing a great job. They just meant that sometimes we needed to make adjustments to better include him.
Also, to be clear, working with Ben to make these tweaks didn’t make me special or heroic. In fact I felt the opposite. I felt embarrassed that I hadn’t questioned the ways we do these things in our workplaces beforehand.
Working like this taught me to pay attention to all the differences, for all the people, that make ways of working harder for some than for others.
Mistakes I’ve made at Local Welcome
Getting lost in our commitment to scale up
During the pandemic we had to stop doing our Local Welcome meals because they weren’t safe. We pivoted to two new services.
As part of our pivot we had one memorable team discussion where we were honest with each other about the problems of the meals model. The results were profound. We admitted that our meals were too complex logistically. That our groups cost so much that they took too long to generate income. And, hardest of all, that our meals had a problematic power dynamic by being about ‘helping refugees’.
My mistake was that I’d been so focused on meeting our commitments to scale up the meals model that I’d found it impossible to step back and see these problems. I need to find better ways to do this in the future.
Agreeing to do too many things at once
In November 2019 we were flying. We’d opened a new group each month since July. We were about to launch in Glasgow and Belfast. We were measuring the impact of our meals. I ran and analysed a huge survey with 500+ leaders and members and we presented our impact to funders to an event on 19 November. It went well.
But at the pub afterwards I had one drink and surprised myself by announcing that I had to take an unplanned week off. I went home exhausted and on the verge of burnout. I promised myself in 2015 I wouldn’t go through a burnout experience again.
My mistake was not saying no to our expansion plans once I realised they were too much work. We could have launched Glasgow and Belfast later. I let our organisational goals overwhelm my personal boundaries.
Failing to hand tasks over quickly enough
We used a work pattern where when we were doing something for the first time - setting up meals in our tech, arranging leader availability across dates, forming partnerships with local refugee organisations - I’d learn by doing and then pass the task onto the team.
When done right this saved us time and got us good outcomes. But on each of the occasions above I didn’t make time to hand these tasks on. I ended up doing some of these for months when I should have been spending my time on other things.
My mistake, at first glance, was not being more ruthless about handing these tasks over quicker. But, going deeper, my mistake was assuming that I had to be the one that did these tasks in the first place.
Automating things before being ready
When I first got my hands on Hubspot I designed a user journey for people that signed up. It took people through a series of automated nudges and prompts to become a paying leader. It handed off user data neatly between Stripe and Hubspot. It catered to all sorts of edge cases.
Except it didn’t work. We didn’t know how to get people to be leaders. We didn’t know how to find leaders or what we expected a leader to do.
My mistake was to get carried away with a technical architecture based on assumptions before I’d worked out the human-first solution. You’d have thought that I’d have avoided that one as a user-centred designer.
Repeating the same mistakes I’ve made before
The frustrating thing is that two of these are mistakes I’ve made before.
Agreeing to do too many things at once - also known as not saying no when I should say no - was the reason that I burned out when designing an online supermarket back in 2015. I’ve been much better at saying no since and it’s why I work a four day week. But it happened again.
Failing to hand tasks on to other people is something I’ve struggled with ever since I started managing people. The tendency to just do something myself rather than taking time to hand it over haunts me.
My mistake here was assuming that just because I knew my previous mistakes I’d be able to avoid repeating them. This clearly wasn’t true. When I was under pressure I reverted to bad habits.
What’s next for me?
I'm not sure yet!
I loved working at Local Welcome. It was the best job that I’ve ever had. A perfect combination of a great concept, a just cause, the freedom to try things out, a wonderful team, and (just enough) money in the bank.
It was my first full-time product role too. I learned about setting a product vision, prioritising work, running a high-performing team, fitting an idea to a market, managing budgets, procuring things, fulfilling legal responsibilities, and setting up a technical architecture. I even learned to go through a radical pivot.
I’m sad that I’m leaving but I’m peaceful about it. My role was always temporary, to get the team to a place where they fly away. I won’t pretend that there aren’t challenges ahead - developing new services is a risky business - but I’m proud of the work that we’ve done over the last two years.
I’m looking for a new product role from January. In a perfect world I’m looking for an interesting idea, that fits with my values, backed by a team of wonderful people, that we can develop together into a successful product for the people that use it and the organisation that runs it.
If you’ve got something then email me on myddelton@gmail.com :)