Counterintuitive Lessons on How to Get Better as You Scale, From Twilio’s Jeff Lawson | First Round Review

13 years after Twilio first launched, CEO and co-founder Jeff Lawson opens up about the peaks and valleys to share a set of unconventional company building lessons on how to get better as you scale — from introducing new products and refining go-to-market strategies, to focusing annual planning and making post-mortems more effective.
— Read on review.firstround.com/counterintuitive-lessons-on-how-to-get-better-as-you-scale-from-twilio’s-jeff-lawson

Reasons Why you Need a Good Acceptance Criteria

What is a User Acceptance Criteria?

User Acceptance Criteria or UAC, is the contract between the product owner and scrum team, letting them know what needs to be done functionality wise, in order to meet the user’s need and exit successfully. A set of explicit and exhaustive conditions, that detail comprehensively the scope of the user story, enabling engineers to understand what they are committing to when they accept a product backlog item into their sprint backlog.

By no means this is a simple exercise and sometimes involve sprint grooming sessions where the product owner and team collaborate to figure out what the minimum subset of functionality should be built.

How to Author User Acceptance Criteria?

There are certain rules that go into writing good UACs, foundational to delivering exactly what is being asked of:

  • Written from a customer’s perspective: Similar to user stories, you should articulate a requirement in the form of a customer journey.
  • Simple enough for anyone to understand: That is, not just your engineers or subject matter experts, but anyone picking up your user story, should be able to read and understand what the conditions for successfully completing it is. This includes being clear and concise, in one simple sentence.
  • Not an Engineering Task: The UAC simple resistances what the user wants, not how, and that is why it is bundled with a user story. The product owner sets what is needed, and the scrum team eventually responds with how, in the form of engineering tasks (or story sub-tasks).

A common approach to writing a user story is using the form Given/When/Then. As an example:

Given I select a profile avatar when scrolling a list of friends, then I should be able to see the user’s full profile. 

As you see, as a product owner, providing clear and concise and exhaustive list of user acceptance criteria as part of the user story, you give your sprint team every chance to assess exactly what work needs to be done, the effort, and thus no surprises during sprint review. Simple enough but something worth re-iterating over and over again.

Better Product Decisions With Experiment-Driven Product Development

Product Managers are always asked upon to justify their product decisions, why invest company resources in a roadmap. In order to back your decisions, you need to be able to prove that it is indeed what the market is asking for, and you are addressing a need. As a product manager myself, I have continually started to rely on a framework that I have become to grow fonder of, and that is Experiment-Driven Product Development, or XDPD for short.

Product Managers are always asked upon to justify their product decisions, why invest company resources in a roadmap. In order to back your decisions, you need to be able to prove that it is indeed what the market is asking for, and you are addressing a need. As a product manager myself, I have continually started to rely on a framework that I have become to grow fonder of, and that is Experiment-Driven Product Development, or XDPD for short.

While it should be the de-facto mindset of product managers, XDPD frames your team’s development through the framework of experiments to uncover the premises which can be based on prior knowledge, assumptions, feature ideas, or claims being made about the product or its users. You start off by development questions that you want to answer, the foundation upon which you would then develop your hypotheses, a statement denoting what your answers might be.

You would then begin to design your experiments in a way that you can prove causality for your hypotheses by selecting a method in which you can run and measure your experiments. The outcome of such exercises would then help you make your decisions, whether it is worth pursuing or abandoning.

The underlying process in creating your hypotheses is that you need to justify why those hypotheses are important, why you need to know the answers to those, and this framework helps you shift the focus from assumptions to the step beforehand, and as the author recites, it seeks to reinforce the basic tenets of Lean while bringing rigors and a different perspective to the approach.

This quarter I found creating a horizontal table where I develop my questions, then hypotheses, followed by how I would measure them. The author of the book makes use of experiment cards, but I simply overlay on a whiteboard the columns for more contextual vision.

PNG image.png
PNG image 2.png

I would recommend you give this framework a try on your next product, and see how it works for you and your team. And don’t forget, take a look at the book that guided me this quarter on product development.