In the Summer of 2016, the Appcues Product team was killing it. If you had a checklist for a high-performing product team, we were nailing all the important marks.
✅ Everything we were building was backed by heavy validation.
✅ We resolved most bugs as soon as they were reported.
✅ Our engineers were in touch with the customers’ needs.
We had developed incredible empathy with customers, the business was growing, and we were miserable.
Although we were heading in the right direction, it came at significant cost. Things that were urgent were prioritized over things that were important. Everything worth building was a massive undertaking (read “epic”), and while customers liked the end result, what shipped was often more than they needed.
Our velocity ground to a near halt and important deadlines came and went.
Not learning fast enough
At an established software company, products are treated as a serious source of revenue because they have proven product-market fit. Early stage startups are different. At a startup, the product is not the revenue stream, it is merely a means for learning what the revenue stream should be. You put something out there, listen to what people say about it, then adjust accordingly.
In the Summer of 2016, we had lost sight of that. We were effectively listening and reacting, but that by itself wasn’t enough to give us major breakthroughs toward product-market fit.
After enough times of me asking for status updates and pushing deadlines, an engineer eventually asked me a question that opened my eyes.
“What’s the consequence of shipping this a week late?”
I didn’t have a good answer.
Let’s face it: most deadlines are arbitrary. As the CEO, imposing arbitrary deadlines would not be out of character for me, but a smart person will realize the emptiness behind my demand. He’d be motivated by the fear of missing the deadline rather than the pride in the accomplishment, and I’d be endorsing a toxic behavior that’s sure to spread.
Frustrated, I did what any PM would do in this situation. I sought a process. I caught up on the latest in Agile Development, interviewed a handful of PMs at other companies and tried to fit what I learned against the type of product team I was trying to build. My ideal process was one that:
- Put the focus on deep, rapid learning above all else.
- Broke work into tiny chunks (1 week or less).
- Communicated internal progress and feedback effortlessly.
This diagram has 3x more people than our entire company did in 2016.
In the end, I came up with a simple, three-part structure that has served us very well.
1. User testing day
Duration: 8 hoursFrequency: monthly
The entire product team — including engineers — does a full day of user testing on the last Thursday of every month. We do 2–3 concurrent tests, often two online and one in-person, co-led by the engineer(s) who built the feature being tested, and we recap together at the end of the day.
We can often get meaty feedback from 10–20 people in a single day using this process.
2. Sprint planning
Duration: 30–60 minutesFrequency: every Monday
The product team gets together at the start of each week to plan and track their progress toward User Testing Day. The conversation starts with, “What do we want to get feedback on?” and then moves to how to accomplish those things before the end of the month.
3. Show & tell
Duration: varies by team sizeFrequency: every Friday
On Friday afternoon, everyone at Appcues gives a short (2–5 minute) presentation on what they did that week. There is some room for giving feedback or answering questions, but it’s mainly about what you accomplished or learned that week.
How everything changed
Our team was already great at interpreting feedback, and this new process kept us focused on getting that raw feedback as rapidly as possible. Through these three meetings, we were able to introduce meaningful deadlines and natural feedback cycles.
User Testing Day creates a meaningful deadline. If you ask an engineer at Appcues why something must ship on time, she’ll tell you, “We already have 15 customers who expect to try this at the end of the month, and it’s a rare opportunity for me to learn how to improve it.” This positive pressure encourages the team to make smart tradeoffs and self-organize around what needs to get done.
Aligning the team around User Testing Day is the key; Sprint Planning and Show & Tell merely keep the train on the track.
Conditions for success
Before you start blasting out recurring calendar invites, be aware of a few conditions that are essential for this process to work.
100% adoption required
This can’t be a repeat of that time you tried to adopt Jobs To Be Done. Nor like that time your team spent the week creating user personas (where are those again?).
The Three Meeting method is a reenforcing system, so each piece needs to be done really well in order for it to work. There are plenty of ways to fail.
- An unclear testing plan sets your team up for public embarrassment rather than praise.
- Ineffective Show & Tells increase the risk of building the wrong thing.
- A lack of user testers undermines the reward for shipping on time.
You’ll need to help everyone understand the purpose of this process. I also recommend meeting with the people on each department to help them craft an effective Show & Tell. While it may seem incompatible with non-product work, some of our best Show & Tells come from our sales and marketing teams.
Radical autonomy
This process is effective because it makes the engineer or designer the star of the show. You, the product manager, help with rehearsal and attract the audience. Do not tell the artist how or what to perform.
Lots of patience
If you’re coming from a more traditional SCRUM process, this will feel really awkward. It will probably feel forced and you’ll be tempted to give up on it.
Stick it out, at least through the first User Testing Day.
If you put all your energy into making sure you have a good first User Testing Day, the value will become clear. Your engineers and designers will look like gods in front of your customers, and they’ll get to hear that first hand. The most important thing to people who make stuff for a living is knowing that someone is going to use and cherish it.
Even if the thing they built doesn’t test well, your team will have a clear idea of what they should do next and be glad they didn’t waste more time going down the wrong path.
If everything goes well, both you and your team will be glad you did it.
The Fourth Meeting
The Three Meetings method has all the benefits and flaws of an oversimplification: it does one thing really really well and sucks at everything else. Things like retrospectives, QA testing and traditional customer research have been left out, so it’s up to you to figure out what role they play for your team and how it affects the dynamic.
Does it scale?
When we first adopted this process, Appcues had four engineers and no designers. Now that we’re seven engineers and one designer, we’ve started to catch glimpses of how this process should scale.
Engineers do planning in smaller groups.The company-wide Show & Tell becomes clumps of cross-functional ones.User Testing Day may be on different days of the month for each team.
We are still early in learning this ourselves, but I feel confident that it can work with a little bit of creativity.
