Product Management – Doron Katz

Working Backwards at Amazon

Amazon’s catalyst for innovation lies in its perspective to always think from the customer backwards. That’s how most successful projects get done, and it all starts with the commonly used Amazonian phrase, working backwards.

Before building a charter, a project plan and setting out timelines, the first artifact that a customer-centric project entails is the publication of a Press Release and FAQ, or PRFAQ for short. This mechanism allows key decision makers to start with what the customer experience articulated through the press would sound like, using the journalism practice of being concise, with the most important paragraphs outlining the entire program, and why customers would get excited about it. This is part of one of Amazon’s most important leadership principles, customer obsession.

Defining the customer experience through the PR, which is no more than six pages, you work backwards and build out the associated FAQ, where you dive deeper into common questions and answers. The FAQ section is where you would outline and iterate on the tough questions that you would anticipate people would ask, by preemptively answering them.

One notable omission in Amazon’s tooling for being customer obsessed, is the lack of PowerPoint presentations, as Colin Bryar and Bill Carr explain, in their book Working Backwards : Insights, Stories, and Secrets from Inside Amazon:

What if we thought of the product concept narrative as a press release? Usually, in a conventional organization, a press release is written at the end of the product development process. The engineers and product managers finish their work, then “throw it over the wall” to the marketing and sales people, who look at the product from the customer point of view, often for the first time. They’re the ones who write the press release, which describes the killer features and fantastic benefits and is designed to create buzz, capture attention, and, above all, get customers to leap out of their chairs to buy.

The authors explain that as most companies take the approach of coming up with a product or business idea that is great for their organizations, they then try to spin a positive light as to why there are unmet customer needs, rather than the other way around. “If the two organizations had started the process by writing a press release, they would have had to agree on the features, cost, customer experience, and price. Then they could have worked backwards to figure out what to build, thereby surfacing the challenges they would face in product development and manufacturing.”

Preparing for an Interview at Amazon Series: Phone Screen

I’ve been at Amazon for just under a year, at the time of writing, and as I approach my first anniversary, I reflect on how I got on this crazy, exciting merry-go-ride, they call Prime Video. I wanted to put down my thoughts on screen as to how I prepared for the interviews, what the interview process was like, and provide some tips for you, if you do get the privilege of going through the interview loop. Mind you, I am giving you just my mere perspective, as a Senior Technical Program Manager, and other roles would certainly have their caveats and domains of expertise.

Phone Screen

Assuming you’ve gone through the online application and have been sought after by a recruiter, phone screening is your entry into the interview loop, your first (and possibly only) opportunity to impress.

At Amazon, our interviews are rooted in behavioral-based questions which ask about past situations or challenges you’ve faced and how you handled them, using Leadership Principles to guide the discussion. We avoid brain teasers (e.g., “How many windows are in Manhattan?”) as part of the interview process. We’ve researched this approach and have found that those types of questions are unreliable when it comes to predicting a candidate’s success at Amazon.

(Source: Amazon)

As a TPM, I had to produce a kind of essay, demonstrating my work style in my previous companies, and of course aligning those with Amazon’s Leadership Principles(LPs), something you should certainly read back to front. Check out some of my other blog posts that dive into some of the leadership principles.

Structure

Your phone interview will consist of behavioral-based questions where you will demonstrate how you resolved past situations, whilst highlighting leadership principle qualities, along the way.

Questions you may face include(source: Amazon):

Tell me about a time when you were faced with a problem that had a number of possible solutions. What was the problem and how did you determine the course of action? What was the outcome of that choice?
When did you take a risk, make a mistake, or fail? How did you respond, and how did you grow from that experience?
Describe a time you took the lead on a project. What did you do when you needed to motivate a group of individuals or promote collaboration on a particular project?
How have you leveraged data to develop a strategy?

Preparing

The first thing you will need to do is build your own experience artifact, by creating an outline using the S.T.A.R method, and use the LPs as your guide for the questions. Then come up with about two or three examples tor each type of LP, variants.

It is critical your set of examples are diverse, don’t use the same example more than once.

Amazon is a data-driven company, so have your answers in S.T.A.R, making sure you are concise and answering the question at hand, along with metrics or data to back up your decision, it will surely help validate your train of thought.

A technique I like to use is to always repeat the question back, to help you ensure you are answering the question correctly, and give you time to provide a balanced structured response.

Finally, be relaxed, let your answers come naturally and not overly manufactured, and be prepared to dive deeper into your responses.

Ask my anything

If you have any questions, please comment below, and I will do my best to answer them!

We are Hiring

Come work with me at Prime Video | Amazon. We are looking for technical program and product managers. Learn about all our cool live and streaming innovations. Based in Seattle or LA. No remote work.

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.

Enterprise Product Development: The Customer Versus the User

As a product manager, it is important that you know who your customer is, and this holds especially true when product developing in an enterprise setting. Take Apple for example, they build beautiful products that factor extreme attention to detail to produce a User Experience (UX) language that makes it intuitive to use and interact with.

Customers you sell a product to in the consumer space have a specific set of skillsets, use cases, and personas that you customize toward, ranging from the MacBook Air college students, to MacBook Pro freelance developers, the family parents who use an iPhone for both work and pleasure.

In the enterprise world, product development personas are different. You cater towards the C-level executive personas, engineers, technical project and product managers, directors, whom have a distinctively different set of selection criterion, when using your product solely in an enterprise environment.

This is why the exercise of persona development, and empathy mapping play a crucial role in helping you understand why you are developing and for whom. Is it a User, or a Customer?

Answering these fundamental questions help you prioritize focus as far as feature development, user experience, and release management. Enterprise engineers may be interested in advanced feature sets, but not so much in the simple polished animations that you would artistically spend time crafting.