rakedbrollback - Tumblr blog

rakedbrollback · 8 years ago

Text

Definition of Done

An agile coach recently asked my department, “What is Definition of Done?” Then he went on to explain, in typical agile coach fashion, about requirements and deliverables, and then I jumped out the window.

To Jeff Bezos, hearing the phrase definition of done probably sounds a lot like what he heard at the 2017 Amazon all-hands meeting: “Jeff, what does Day 2 look like?” Why would someone ask that? Well, here is Jeff’s 2016 Letter to Shareholders, in which he explains his “Day 1″ philosophy and how it relates to done-ness.

April 12, 2017

“Jeff, what does Day 2 look like?”

That’s a question I just got at our most recent all-hands meeting. I’ve been reminding people that it’s Day 1 for a couple of decades. I work in an Amazon building named Day 1, and when I moved buildings, I took the name with me. I spend time thinking about this topic.

“Day 2 is stasis. Followed by irrelevance. Followed by excruciating, painful decline. Followed by death. And that is why it is always Day 1.”

To be sure, this kind of decline would happen in extreme slow motion. An established company might harvest Day 2 for decades, but the final result would still come.

I’m interested in the question, how do you fend off Day 2? What are the techniques and tactics? How do you keep the vitality of Day 1, even inside a large organization?

Such a question can’t have a simple answer. There will be many elements, multiple paths, and many traps. I don’t know the whole answer, but I may know bits of it. Here’s a starter pack of essentials for Day 1 defense: customer obsession, a skeptical view of proxies, the eager adoption of external trends, and high-velocity decision making.

True Customer Obsession

There are many ways to center a business. You can be competitor focused, you can be product focused, you can be technology focused, you can be business model focused, and there are more. But in my view, obsessive customer focus is by far the most protective of Day 1 vitality.

Why? There are many advantages to a customer-centric approach, but here’s the big one: customers are always beautifully, wonderfully dissatisfied, even when they report being happy and business is great. Even when they don’t yet know it, customers want something better, and your desire to delight customers will drive you to invent on their behalf. No customer ever asked Amazon to create the Prime membership program, but it sure turns out they wanted it, and I could give you many such examples.

Staying in Day 1 requires you to experiment patiently, accept failures, plant seeds, protect saplings, and double down when you see customer delight. A customer-obsessed culture best creates the conditions where all of that can happen.

Resist Proxies

As companies get larger and more complex, there’s a tendency to manage to proxies. This comes in many shapes and sizes, and it’s dangerous, subtle, and very Day 2.

A common example is process as proxy. Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations. The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you’re doing the process right. Gulp. It’s not that rare to hear a junior leader defend a bad outcome with something like, “Well, we followed the process.” A more experienced leader will use it as an opportunity to investigate and improve the process. The process is not the thing. It’s always worth asking, do we own the process or does the process own us? In a Day 2 company, you might find it’s the second.

Another example: market research and customer surveys can become proxies for customers – something that’s especially dangerous when you’re inventing and designing products. “Fifty-five percent of beta testers report being satisfied with this feature. That is up from 47% in the first survey.” That’s hard to interpret and could unintentionally mislead.

Good inventors and designers deeply understand their customer. They spend tremendous energy developing that intuition. They study and understand many anecdotes rather than only the averages you’ll find on surveys. They live with the design.

I’m not against beta testing or surveys. But you, the product or service owner, must understand the customer, have a vision, and love the offering. Then, beta testing and research can help you find your blind spots. A remarkable customer experience starts with heart, intuition, curiosity, play, guts, taste. You won’t find any of it in a survey.

Embrace External Trends

The outside world can push you into Day 2 if you won’t or can’t embrace powerful trends quickly. If you fight them, you’re probably fighting the future. Embrace them and you have a tailwind.

These big trends are not that hard to spot (they get talked and written about a lot), but they can be strangely hard for large organizations to embrace. We’re in the middle of an obvious one right now: machine learning and artificial intelligence.

Over the past decades computers have broadly automated tasks that programmers could describe with clear rules and algorithms. Modern machine learning techniques now allow us to do the same for tasks where describing the precise rules is much harder.

At Amazon, we’ve been engaged in the practical application of machine learning for many years now. Some of this work is highly visible: our autonomous Prime Air delivery drones; the Amazon Go convenience store that uses machine vision to eliminate checkout lines; and Alexa, our cloud-based AI assistant. (We still struggle to keep Echo in stock, despite our best efforts. A high-quality problem, but a problem. We’re working on it.)

But much of what we do with machine learning happens beneath the surface. Machine learning drives our algorithms for demand forecasting, product search ranking, product and deals recommendations, merchandising placements, fraud detection, translations, and much more. Though less visible, much of the impact of machine learning will be of this type – quietly but meaningfully improving core operations.

Inside AWS, we’re excited to lower the costs and barriers to machine learning and AI so organizations of all sizes can take advantage of these advanced techniques.

Using our pre-packaged versions of popular deep learning frameworks running on P2 compute instances (optimized for this workload), customers are already developing powerful systems ranging everywhere from early disease detection to increasing crop yields. And we’ve also made Amazon’s higher level services available in a convenient form. Amazon Lex (what’s inside Alexa), Amazon Polly, and Amazon Rekognition remove the heavy lifting from natural language understanding, speech generation, and image analysis. They can be accessed with simple API calls – no machine learning expertise required. Watch this space. Much more to come.

High-Velocity Decision Making

Day 2 companies make high-quality decisions, but they make high-quality decisions slowly. To keep the energy and dynamism of Day 1, you have to somehow make high-quality, high-velocity decisions. Easy for start-ups and very challenging for large organizations. The senior team at Amazon is determined to keep our decision-making velocity high. Speed matters in business – plus a high-velocity decision making environment is more fun too. We don’t know all the answers, but here are some thoughts.

First, never use a one-size-fits-all decision-making process. Many decisions are reversible, two-way doors. Those decisions can use a light-weight process. For those, so what if you’re wrong? I wrote about this in more detail in last year’s letter.

Second, most decisions should probably be made with somewhere around 70% of the information you wish you had. If you wait for 90%, in most cases, you’re probably being slow. Plus, either way, you need to be good at quickly recognizing and correcting bad decisions. If you’re good at course correcting, being wrong may be less costly than you think, whereas being slow is going to be expensive for sure.

Third, use the phrase “disagree and commit.” This phrase will save a lot of time. If you have conviction on a particular direction even though there’s no consensus, it’s helpful to say, “Look, I know we disagree on this but will you gamble with me on it? Disagree and commit?” By the time you’re at this point, no one can know the answer for sure, and you’ll probably get a quick yes.

This isn’t one way. If you’re the boss, you should do this too. I disagree and commit all the time. We recently greenlit a particular Amazon Studios original. I told the team my view: debatable whether it would be interesting enough, complicated to produce, the business terms aren’t that good, and we have lots of other opportunities. They had a completely different opinion and wanted to go ahead. I wrote back right away with “I disagree and commit and hope it becomes the most watched thing we’ve ever made.” Consider how much slower this decision cycle would have been if the team had actually had to convince me rather than simply get my commitment.

Note what this example is not: it’s not me thinking to myself “well, these guys are wrong and missing the point, but this isn’t worth me chasing.” It’s a genuine disagreement of opinion, a candid expression of my view, a chance for the team to weigh my view, and a quick, sincere commitment to go their way. And given that this team has already brought home 11 Emmys, 6 Golden Globes, and 3 Oscars, I’m just glad they let me in the room at all!

Fourth, recognize true misalignment issues early and escalate them immediately. Sometimes teams have different objectives and fundamentally different views. They are not aligned. No amount of discussion, no number of meetings will resolve that deep misalignment. Without escalation, the default dispute resolution mechanism for this scenario is exhaustion. Whoever has more stamina carries the decision.

I’ve seen many examples of sincere misalignment at Amazon over the years. When we decided to invite third party sellers to compete directly against us on our own product detail pages – that was a big one. Many smart, well-intentioned Amazonians were simply not at all aligned with the direction. The big decision set up hundreds of smaller decisions, many of which needed to be escalated to the senior team.

“You’ve worn me down” is an awful decision-making process. It’s slow and de-energizing. Go for quick escalation instead – it’s better.

So, have you settled only for decision quality, or are you mindful of decision velocity too? Are the world’s trends tailwinds for you? Are you falling prey to proxies, or do they serve you? And most important of all, are you delighting customers? We can have the scope and capabilities of a large company and the spirit and heart of a small one. But we have to choose it.

A huge thank you to each and every customer for allowing us to serve you, to our shareowners for your support, and to Amazonians everywhere for your hard work, your ingenuity, and your passion.

As always, I attach a copy of our original 1997 letter. It remains Day 1.

Sincerely,

Jeff

You can access all Amazon shareholder letters here.

0 notes

rakedbrollback · 8 years ago

Text

The Product Triathlon (3X)

Kent Beck, the creator of XP (Extreme Programming) and one of the original Agile Manifesto signatories, has recently been pushing a new product development model: the Product Development Triathlon, or 3X for short. The triathlon has three parts: Explore, Expand, Extract.

(from his talk at Andela - Nairobi, in December 2016)

Explore: As many experiments as possible, as quickly as possible, to figure out what we should dedicated our resources to.

Expand: We now know what to focus on, so all we care about is growth. We have to work like hell to do whatever we gotta to grow that user base.

Extract: Super boring / not taking any chances / 100% refinement. "Can we increase global advertising sales by .3%? Let's talk about it. Yep, should definitely invite Legal to the meeting."

The explore phase, in which we're looking for success, is very experimental. "You can't predict success," he says, "so your goal is to run as many experiments as possible to arrive at something that works." Then, like God suggesting that faith is overrated, Kent says, "When I'm looking for a product-market fit, for that positive feedback loop... [code] quality is irrelevant, as the half-life of your software is just a few hours." Go back to rules of XP, and tell me that quote matches its ethos.

Crazy, right? It makes sense, though. When you don't know how to achieve success, why not throw shit at the wall and see what sticks? But, how much shit is appropriate? Not a little, only a lot. We shouldn't take a week to prepare a little dingleberry, watch it fall off the wall over the next couple weeks, then debate with amongst ourselves about whether or not to throw another. Let's go to Whole Foods, buy a big bag of prunes, use the same bag to catch all the shit we excrete, then throw that pile against the wall and see what sticks. "The Lean Startup is the best framework I've seen for this, so far," he says.

Once we find something that works, we're ready to enter the expand phase. Here, we're focused on growth. Yes, we might lose some customers in the process, but the alternative is death. "Expansion is the most valuable part of this curve, by far," he says. "This isn't the time to jeopardize growth by adding features. Invest money in fixing the problems you need to address now."

Expansion takes guts, speed, agility (not just Agility), and happy hours. It's tough, but quick. In my opinion, of all the Agile frameworks, kanban is probably best suited to handle this phase. But then again, I'm not a huge fan of Agile frameworks, in general--but that's another email.

Once we've know what to do and how to do it, we’re ready for the extract phase. “One euro in equals three euros out,” according to Kent. “Playbooks emerge: here’s how you roll out the service in a new city. Economies of scale matter: delivering the service at lower cost is more profitable.” This is the space that most large organizations live. It’s a very conservative space, because there’s a lot to lose. When we’re in the explore phase, we have, what, 10 users? That’s basically zero, so if we lose them, then whatever. In the extract phase, what do we have, 1,000,000 daily users? OK, let’s be very careful before we throw shit on the wall. We’re probably not going to discover one line of code that that’ll get us from 1 million to 30 million daily users, overnight. So, let’s not risk the ship sinking.

#kent beck #product development #product triathlon #3X

0 notes