# data[].attributes.attachment_link.readable_text
Using agile tools and techniques can help your digital service team to:

self-organise and plan

communicate (within the team and with the rest of your organisation)

continuously improve the way you work

get support from senior responsible officers (SROs) and service managers

You might also hear these tools and techniques called 'agile ceremonies and artefacts'.

Daily standup

The standup is a daily meeting for the team to discuss what they're working on and whether there are any problems or dependencies they need to resolve (for example, needing help from someone else).

Standups should last no longer than 15 minutes. You should hold them at the same time every day. It's best if you do it standing up in front of your team wall.

good and bad standups - a video presentation by Adam Maddison, Head of Agile Delivery at Government Digital Service (GDS)

See: standup meetings on Wikipedia

Sprint planning meetings

Sprint planning meetings are a feature of Scrum. You should hold them at the start of each sprint.

At a sprint planning meeting, the team decides what to work on next and how they'll do it.

The length of the meeting will depend on how long your sprint is.

See: sprint planning by Ken Schwaber and Jeff Sutherland, the creators of Scrum

Team review (show and tell)

The team review is a regular meeting which gives team members the opportunity to demonstrate their work. It can also be called a sprint review or a show and tell.

You can invite stakeholders like directors or suppliers to this meeting and use it to tell them about the user stories you've completed or other work you've done.

You'll need a screen to show your work and enough space for people to join in.

If your service is part of a larger organisation or programme you may want to open up your review to the rest of the organisation every few weeks.

This gives you the opportunity to show the most important work you've done, talk about what you've learned, explain your plans for the next few weeks and answer questions. It also gives other teams the chance to see how your work relates to theirs.

See: how a Ministry of Justice team got stakeholders involved in sprint reviews

Retrospective meetings

Retrospectives, sometimes called 'retros', are regular meetings where your whole team talks about what's going well and what isn't.

Teams usually hold retros at the end of an iteration (for example a sprint) and use them to talk about the work from that period of time.

The point of a retro is to fix any problems in the team and to make sure you keep doing the things that are working.

How to run a retro

One person should host the retro and decide on questions for the team to talk about.

If you're hosting, pick broad questions that allow the team to set the agenda, rather than strictly setting it yourself.

Retros should have an open atmosphere where every member of the team can speak honestly and feel confident that their colleagues will listen.

Allow 60 to 90 minutes for the meeting and use a private space where you can stick post-it notes to the wall.

A basic retro could follow these steps:

1. The host explains the questions at the beginning and sticks a post-it note to the wall for each question.

2. Each team member writes down one or more answers for each question on post-it notes and sticks them to the right part of the wall.

3. The group discusses issues as they come up, or at the end.

4. The host decides on actions to fix any problems raised, and assigns them to members of the team.

You could choose to cover 3 or 4 of the following topics:

what went well in the last iteration

what went badly in the last iteration

what's puzzling the team or what the team doesn't understand

who the team wants to thank (eg other members of the team)

These topics are just examples, there are many different types of retro. You can find more in the Retrospective wiki.

If you're hosting the retro, you should pick topics which you think will prompt useful discussions in your team, for example on transparency, team learning or your working process.

Make a list of actions

You should use the information you get from your retro to improve your work and your working environment.

Make a list of actions that you'll carry out to fix the problems that your team highlighted and assign them to people in the team.

You should aim to get the actions done before the next retro.

End-of-phase retrospectives

Some teams run a longer retro at the end of discovery, alpha and beta. These usually include people who've been involved in the work from outside the team, too, like procurement or policy colleagues.

This type of retro can:

identify what could be improved in the next phase of the project

help people from procurement, policy or other disciplines work more effectively with service teams across the wider organisation

ONS ran an end-of-phase retro to identify which ways of working to continue and which to stop in the next phase of their data discovery project.

User stories

User stories are a way for your team to briefly record the things you need to do to build the service. You can use them to prompt discussions about features when you're ready to start work on them.

See: writing user stories

The backlog

Your team will have a product backlog where you'll store the user stories you haven't started work on yet in order of priority. If you're following Scrum methodology you'll also have a sprint backlog to store the stories the team has agreed to work on in that sprint.

See:

Team walls

Your team wall is a wall near where you sit on which you keep a visual record of your work.

The wall shows what your team has done, what they're currently doing and the work still to do.

It helps your team to collaborate and allows other people in the organisation to see what you're doing.

See:

You may also find these guides useful:

# data[].attributes.attachment_link.description
Using agile tools and techniques can help your digital service team to: self-organise and plan communicate (within the team and with the rest of your organisation) continuously improve the way you work get support from senior responsible officers (SROs) and service managers You might also hear these tools and techniques called 'agile ceremonies and artefacts'.

# data[].attributes.attachment_link.title
User-Centred Design - Online Content Design Course - FutureLearn

# data[].attributes.attachment_link.description
Get to grips with content design with the experts from the Government Digital Service and enhance your digital content using effective user-centred design methods.

# data[].attributes.attachment_link.description
Dive deep or get a quick dose of our design best practices and Figma tips and tricks.

# data[].attributes.attachment_link.readable_text
When designing a government service, always start by learning about the people who will use it. If you don't understand who they are or what they need from your service, you can't build the right thing.

Understanding user needs

People and businesses use government services to help them get something done (for example, register to vote, check if a vehicle is taxed or pay a VAT bill).

'User needs' are the needs that a user has of a service, and which that service must satisfy for the user to get the right outcome for them.

Services designed around users and their needs:

are more likely to be used

help more people get the right outcome for them - and so achieve their policy intent

cost less to operate by reducing time and money spent on resolving problems

Researching users and their needs

You must keep researching throughout each development phase to make sure your service continues to meet user needs.

When to research

In the discovery phase, you should find out:

who your likely users are and what they're trying to do

how they currently do it (for example, what services or channels they use)

the problems or frustrations they experience

what users need from your service to achieve their goal

In the alpha, beta and live phases, you should:

improve your understanding of your users and their needs

test design ideas and new features with likely users

assess users' experience of your service, to make sure it meets their needs

How to research

You can learn about users and their needs by:

reviewing existing evidence (for example, analytics, search logs, call centre data, previous research reports, data from Citizens Advice etc)

interviewing and observing actual or likely users

talking to people inside and outside your organisation who work with actual or likely users (for example, caseworkers, call centre agents and charity workers)

Treat any opinions or suggestions that don't come from users as assumptions that have to be proven by doing research.

Who to research with

You must understand the needs of all kinds of users, not just 'typical' users. You also have to consider the needs of people who provide the service or support other users (for example, caseworkers, call centre agents, inspectors, lawyers and charity workers).

When researching, focus on users who have problems using existing services or getting the right outcome for them. This will help you create a simpler, clearer, faster service that more people can use.

Writing user needs

Once you have a good understanding of your users' needs, you should write them down and add them to your descriptions of users.

User needs are usually written in the format:

I need/want/expect to... [what does the user want to do?]

So that... [why does the user want to do this?]

If it's helpful, you can add:

As a... [which type of user has this need?]

When... [what triggers the user's need?]

Because... [is the user constrained by any circumstances?]
Example:
As a [British person]

I need [a passport]

So that [I can travel abroad and prove my identity]

Write user needs from a personal perspective using words that users would recognise and use themselves.

Focus on what's most important for your users so you don't create an unmanageable list of user needs.

Validating user needs

Good user needs should:

sound like something a real user might say

be based on evidence from user research, not assumptions

focus on the user's problem rather than possible solutions (for example, needing a reminder rather than needing an email or letter)

As you progress through the development phases, use what you learn to continually validate and refine your user needs.

Once you've learned about your users and their needs, you should share what you know with anyone who's interested in your service, including colleagues, stakeholders, users and the public.

You should present what you've learned a in a way that's easy for others to understand and share. For example:

experience maps that show how users interact with existing or future services and the needs they have at each stage (register, apply, interview etc)

user profiles or personas that describe groups of users with similar behaviour and needs (new parent, caseworker, small business etc)

The more you share, the more others will understand about your users and what they need from your service. They'll also ask questions, spot gaps and comment on what you're doing - all of which will help you design a better service.

User needs tend to be high-level, broad in scope and stable over time.

As you design your service, you'll use them to write user stories. These describe the specific features and content you need to create for your service to meet your users' needs.

User stories are normally written in a more constrained format than user needs and include additional information like acceptance criteria, level of complexity and dependencies. Teams use them to organise work into manageable chunks that create tangible value.

When writing a user story, you should keep track of the user needs it relates to. This traceability allows you to track related activities and determine how well you're meeting a particular user need.

You may find the following guides useful:

You might also want to read the Performance Platform team's blog about understanding the needs of service data users.

# data[].attributes.attachment_link.description
When designing a government service, always start by learning about the people who will use it. If you don't understand who they are or what they need from your service, you can't build the right thing. People and businesses use government services to help them get something done (for example, register to vote, check if a vehicle is taxed or pay a VAT bill).

# data[].attributes.attachment_link.readable_text
1. Start with user needs

Service design starts with identifying user needs. If you don't know what the user needs are, you won't build the right thing. Do research, analyse data, talk to users. Don't make assumptions. Have empathy for users, and remember that what they ask for isn't always what they need.

2. Do less

Government should only do what only government can do. If we've found a way of doing something that works, we should make it reusable and shareable instead of reinventing the wheel every time. This means building platforms and registers others can build upon, providing resources (like APIs) that others can use, and linking to the work of others. We should concentrate on the irreducible core.

3. Design with data

In most cases, we can learn from real world behaviour by looking at how existing services are used. Let data drive decision-making, not hunches or guesswork. Keep doing that after taking your service live, prototyping and testing with users then iterating in response. Analytics should be built-in, always on and easy to read. They're an essential tool.

4. Do the hard work to make it simple

Making something look simple is easy. Making something simple to use is much harder - especially when the underlying systems are complex - but that's what we should be doing. Don't take "It's always been that way" for an answer. It's usually more and harder work to make things simple, but it's the right thing to do.

5. Iterate. Then iterate again

The best way to build good services is to start small and iterate wildly. Release minimum viable products early, test them with actual users, move from alpha to beta to live adding features, deleting things that don't work and making refinements based on feedback. Iteration reduces risk. It makes big failures unlikely and turns small failures into lessons. If a prototype isn't working, don't be afraid to scrap it and start again.

6. This is for everyone

Accessible design is good design. Everything we build should be as inclusive, legible and readable as possible. If we have to sacrifice elegance - so be it. We're building for needs, not audiences. We're designing for the whole country, not just the ones who are used to using the web. The people who most need our services are often the people who find them hardest to use. Let's think about those people from the start.

7. Understand context

We're not designing for a screen, we're designing for people. We need to think hard about the context in which they're using our services. Are they in a library? Are they on a phone? Are they only really familiar with Facebook? Have they never used the web before?

8. Build digital services, not websites

A service is something that helps people to do something. Our job is to uncover user needs, and build the service that meets those needs. Of course much of that will be pages on the web, but we're not here to build websites. The digital world has to connect to the real world, so we have to think about all aspects of a service, and make sure they add up to something that meets user needs.

9. Be consistent, not uniform

We should use the same language and the same design patterns wherever possible. This helps people get familiar with our services, but when this isn't possible we should make sure our approach is consistent.

This isn't a straitjacket or a rule book. Every circumstance is different. When we find patterns that work we should share them, and talk about why we use them. But that shouldn't stop us from improving or changing them in the future when we find better ways of doing things or the needs of users change.

10. Make things open: it makes things better

We should share what we're doing whenever we can. With colleagues, with users, with the world. Share code, share designs, share ideas, share intentions, share failures. The more eyes there are on a service the better it gets - howlers are spotted, better alternatives are pointed out, the bar is raised.

Much of what we're doing is only possible because of open source code and the generosity of the web design community. We should pay that back.

# data[].attributes.attachment_link.description
Service design starts with identifying user needs. If you don't know what the user needs are, you won't build the right thing. Do research, analyse data, talk to users. Don't make assumptions. Have empathy for users, and remember that what they ask for isn't always what they need.

# data[].attributes.attachment_link.readable_text
PMs get sad when you ask them why they exist

There is a rite of passage in the product management world, where all PMs have experienced being asked:
"What does a product manager do, anyway?"
I empathize with designers and engineers for asking this question. In their shoes, I would be just as skeptical, because a product manager's activities are fragmented, and don't reveal the true discipline beneath.

When I first started in product management, I didn't even know I was doing it. Instead, I was a first time founder and thought I was just "doing startup".

Later, when I interviewed for a PM job, some much more qualified people told me that I was, in fact, doing product management. I got the job. Early into that role, I was asked the infamous question above. I wasn't offended; in fact, I was just as curious as them, so I started reading (and reading) about product management. The internet said many things:

I wasn't a project manager, and I should be offended if someone infers that

I was supposed to own the what and the why

I should be a visionary, the voice of the customer, Mr. get shit done, etc.

I soaked it all in. I re-readGood Product Manager, Bad Product Manager - mybible of product management - weekly, for the first few months.

And then I shipped, and shipped some more. And pretty soon I felt useful.

Years into that job, I started managing other product teams. Other PMs were now looking to me to define expectations, so that they could now respond to questions of why they existed. I offered a cocktail of the best posts I'd read, and examples of the experiences I'd had over the years.

I'm currently at Shopify in my third role in product, and again I find myself rethinking assumptions about what it is I truly do. Shopify is a true engineering culture, and has very few product managers relative to the size of the company. For perspective, my last company had 1:10 ratio of PMs to employees. Shopify (including directors) is closer to 1:80.

An engineer asked me "the question" the first week I was there.

One of the best things about working here has been observing an alternative approach to how products can be built and shipped effectively. Shopify engineers and designers are incredibly talented, opinionated and independent, and learning to effectively work with them has forced me to change the way I perceive my craft.

It's also forced me to figure out what shouldn't change, and in doing so, push me to abstract away the what in favour of the why. This post isn't about Shopify, nor is it about the how to be an effective product manager. It's about why product management exists.

Product Management is the by-product of two exponential forces being exerted on a company.

1. Speed: The company exists in an industry where the rate of technological innovation is accelerating

2. Scale: Growth in the company's product, organization, and customers are creating complexity

Speed is an exponential force because with every period of time, more change is occurring than in the last. Similarly with scale; every extra feature, employee, or user is adding more complexity to the system than the last.

The reason product management as a career has been popularized in predominantly software companies, is because software is inherently fast and scalable.

The internet changed how software products were delivered to the market. Long gone are the days of annual releases and cardboard boxes on shelves. For the last two decades, teams have been writing code, deploying it, and giving updates to all their customers instantaneously.

Software development itself has a lowered bar of entry. Approachability of high level programming languages, and the prevalence of open source libraries has super charged developers with unprecedented productivity. At the same time, the infrastructure costs of building a functional product and deploying it has dropped to basically zero.

This means that every large problem in the world likely has hundreds of independent teams working to solve it.

In this way, speed has two meanings: both how quickly you can get something to market with software development, and (critically) how competition forces companies to go faster to survive.

The reason why sub 50-person startups rarely have product managers is that the complexity is still manageable. The CEO and co-founders are still able to coordinate the company towards a focused problem and unleash the power of a scrappy startup upon it.

But as the company grows, complexity emerges as more features are added, customers become more diverse, and the team grows. And that complexity grows exponentially.

For example, how many meetings do you think a 20-person startup can have?

The answer shows why we suck at conceptualizing the exponential.

The problem the company solves grows in complexity as well. As teams solve high level problems, they spawn hundreds of derivative problems, all begging to be solved. The catch is the company can't solve them all. Faced with hundreds of problems to solve, choosing where to focus quickly becomes the most important decision a company makes.

A Cocktail of Chaos

When you consider the simultaneous impacts of speed and scale on a company, it's easy to conceptualize how things will eventually derail without someone thinking holistically about the company. Ultimately, that role is for the CEO, but when they've reached their multi-tasking limits, who else can fill the void?
Sure, products need some oversight - got it. Why not just train everyone to be able to manage the product, why hire a specific role?
The short answer is that it's harder than you think to manage a product, and it takes years of experience to become capable. Here's the long answer:

The core competency of a product manager is truly understanding product development. That is, how to identify which problem to solve and how to work with a team to solve it.

Anyone who's been through a few launches knows that despite the textbooks, a linear product development process like the one below is a fairy tale.

Even if you included feedback loops between the steps, the idea of neat and tidy sequential steps, where functional teams work together through a checklist is flawed. It simply does not fit into a world where technology is progressing exponentially.

The world changes too quickly for us to build on research we had even three months ago.

I view modern product development as a system of interconnected disciplines, working in a network, to deliver on a user's desire. Product managers are the API that facilitates communication in this network.

Each node represents a broad bucket of domain expertise, each with enough depth that people dedicate careers to master them. This is an important quality of product development in a company where speed and scale have reached critical mass: there's too much to know, so only a team can effectively deliver a product.

The process of product development is how this system moves through time.

Product managers shepherd this system from problem identification through to product launch, ensuring that each node in the network is aware of the progression of the others, and that users increasingly want what is being developed.

Finally, organizational scale brings with it multiple teams. And an effective product development system coordinates and focuses those teams towards the company's vision.

As the product development APIs, product managers support company wide efficiency by ensuring no duplication of effort, and sharing infrastructure to enable other teams to go faster.

Product managers spend years to develop the skills required to be responsible for this system. It's a multidisciplinary, breadth over depth approach to learning.

In my career, I've done all of: programming, UI design, UX research, financial modelling, business development, support, copy-writing, accounting, legal, contract negotiation, reporting, marketing, blog posts, FAQs, and product copy.

I've been an expert in none, and achieved borderline competence in some. I knew just enough of each to be useful as an API, but never enough to be dangerous (in a good way). That's the quintessential quality of a product manager's skill set, one that makes it hard for builder types to grok exactly what value they bring.

PMs know just enough of each discipline to be responsible for the entire product development system.

A product manager's multidisciplinary awareness enables them to communicate in whatever language is necessary to effectively deliver information across the team.

They're also in the best position to assess the impact of change across the system. A recent conversation I had with Shopify's CEO, expressed this pretty succinctly to me.

"Great product people understand how a change in the way the world works will impact the log files. And they can perceive that impact in real time."

- Tobi Lütke [paraphrased]

Exactly right.

In a world where speed is king and the world is changing exponentially, having time to develop consensus before action is often a luxury. Teams need critical decisions made on a daily basis in order to maintain speed, and those decisions have major trade offs and/or conflicting interests among stakeholders.

Driving those decisions is no one else's job but the product manager's.

Whereas the work of engineers and designers are easier quantified, because it's difficult to observe a PMs impact over the short run, the ambiguity around Product Management will remain for some time.

One day, there may be graduate degrees and definite career paths to product management, but not today. Until then, companies will continue to scale, the world will continue to get faster, and sooner or later "we need someone to manage this" will get proposed.

If you're a PM, don't get butt-hurt the next time someone challenges your existence. Embrace ambiguity (you're a PM, after all) and have confidence in your purpose.

# data[].attributes.attachment_link.description
There is a rite of passage in the product management world, where all PMs have experienced being asked: "What does a product manager do, anyway?" I empathize with designers and engineers for asking this question. In their shoes, I would be just as skeptical, because a product manager's activities are fragmented, and don't reveal the true discipline beneath.

# data[].attributes.headline
Why Chefs and Soldiers Make the Best Product Managers

# data[].attributes.subject
Why Chefs and Soldiers Make the Best Product Managers

# data[].attributes.attachment_link.readable_text
Five years ago, Clover Health COO Wilson Keenan got his first job in product management. Before that, he was a line cook. It wasn't his only work experience, but it's what stood out to the man who hired him, Jim Patterson - then Chief Product Officer at Yammer, now CEO of cannabis technology startup Eaze. In fact, it fit into a broader hiring philosophy Patterson subscribes to: chefs and soldiers make excellent product managers.

"Both the military and professional kitchens are environments where there's zero tolerance for slackers and indecision - you have to be on all the time, working quickly under high pressure," he says. "When Wilson told me he'd worked at that job for a year I thought, 'He must be good.' Otherwise you get bounced out of that industry immediately."

Making good decisions quickly isn't the only quality PMs need that military or kitchen experience instills. There's a whole checklist Patterson looks for whenever he makes product hires:

Being able to lead without authority.

Always taking blame while giving credit away.

Strong decision-making with imperfect information.

Valuing intense preparation.

Methodical in how they recover from mistakes and crises.

Operating optimally under extreme pressure.

While very few may actually be former chefs or soldiers, this list can serve as a rubric for hiring product managers who have the raw skills to succeed in the role. In this exclusive interview, Patterson - who served in the Air Force - shares what he looks for and how he thinks about building uniquely effective product teams. He also explains Eaze's 'War Room' strategy for consistently beating its goals leveraging a similar, military-style mentality.

Great PMs Earn Authority with Respect and Consistency

Product is this tough job where no one truly works for you. The engineering team doesn't report to you. They don't really have to do what you say, but you have to be their leader anyway.

If you're a cook in a restaurant or commercial kitchen, you're usually one of many, constantly handing off work to one another to achieve a highly-orchestrated result. In the military, there's strict hierarchy, but there's also a lot of teamwork among peers. In these situations, natural leaders who win the allegiance of those around them thrive.

"Being charismatic and well-spoken is important, but it's not sufficient on its own," says Patterson. "It's possible to learn to be a good leader, because it's really about credibility and respect."

This is why product managers with technical ability tend to have an advantage. They start off with instant credibility because engineers feel that they speak the same language, understand the scope of challenges, and operate accordingly. These PMs don't have to be former engineers, themselves - they just have make the effort to use the right terminology and learn what projects require from an engineering perspective.

"You have to make it clear you respect what engineers do as a craft - it's not just a means to an end or a route to a company goal - it's creating something from nothing in a way that requires considerable creativity and skill," he says. "Don't be a wet noodle leader. If you push a wet noodle, it goes nowhere. You have to pull it. Don't push or try to game engineers into doing things. Pull them with a vision for what they could build, the opportunity, and the impact they can make."

The most important thing any PM has going for them is the trust of the engineers. You need to be able to chart a course that may not have 100% consensus - that many may not understand - but they'll follow you because they trust you. The best way to create that trust is to build a consistent track record of sound decision making with no fanfare - day in, day out.

Great PMs Make Being Thankless a Habit

"When you're in basic training and one person messes up, the whole unit ends up doing push-ups," says Patterson. "It's how they reinforce that you're a team that fails and succeeds together. You learn that when you screw up, it's not just you. It affects everyone else."

The best product managers know they have thankless jobs, and they don't mind. This is a skill unto itself. They never throw anyone else under the bus. They know as soon as they point a finger at engineering, they're done. Subtle sabotage by engineers should be the greatest fear of every PM, and it happens all the time, he says.

"No matter how many times it gets said, I still see product managers out there hung up on themselves, being dismissive of engineers, treating them like cogs in the wheel," says Patterson. "They never last long. On more than a few occasions when I headed product, engineers would come to me and say, 'I can't work with so-and-so.' And I'd let that PM go, because there was no coming back from that."

Given all his experience, he says this quality now helps him separate the best PMs from the rest.

"I can tell who the 'mid-level' people are. They're always selling themselves. They want to make sure that I know all the things they're working on and how hard they're working," he says. "The top PMs understand if your team is bad, you're bad. If your team is good, you're good. The worst thing you can do as a PM is blame members of your team. If you do that, you're dead, because they will not have your back after that."

When things go well, you want a PM who gets out of the way and points to everyone else. Not everyone is capable of this.

If you crave approval, this job isn't for you.

The best way to root out this mentality is to pay attention to pronouns. In an interview, does a PM candidate say 'I' and 'me' a lot? Or do they say 'we', 'my team' and 'us.' "People can't help it. I'll actually start to count the number of times they say each thing. I've been in interviews where someone says 'I' 50 times - 'I did this, I did that.' They came from a big company. There's no way they did all of that alone."

Especially at a startup, you want your product managers to be servant-leaders. Do they have a history of operating in service to engineers, to designers, to fellow PMs? How has this manifested?

"It's the little things. When they order pizza for the team, who gets the first slice? Do they wait until others have gotten theirs?" Patterson says. "Do they show up to meetings not just on time but early? It's a show of respect for other people's time." Some of this may be hard to suss out while interviewing someone, but it's easy to observe and correct once you have them on board to maximize success.

Great PMs Move Fast Without All the Facts

Military service drills you in making quick decisions with imperfect information. It's the basis of one of Patterson's favorite sayings: " Mostly right, never in doubt. " That's what PMs need to be too.

It's also why the Air Force created the - which stands for Observe, Orient, Decide and Act. The key is, every time the loop finishes, it's starts all over again, integrating new information prompted by the last action. It's been used for years to train pilots to make quick decisions in extremely high-pressured situations.

The OODA Loop is also a helpful tool for product managers, who - Patterson argues - should assume that the data they have is always imperfect and will never be perfect. "A lot of people find it very difficult to pull the trigger on something until they feel like they have all the info, they gather, gather, gather and never act," he says. "Like pilots, PMs can't do this. They'll never ship on time if they do."

Instead, they need to keep running the loop - taking in all the information available to them, deciphering what it means, making firm decisions, and deploying them. It requires both endurance - because you have to keep at it day after day - and the precision to make the smartest possible decision at any given point.

"I look for PMs who are more about perfecting process than perfecting outcomes," he says. "If there was a bad outcome, I want someone who will backtrack to figure out what information went into the decision. Maybe it's the best that could have possibly been done given the data on hand. Maybe it's the process of how the decision got made that could be better." By asking these questions, good PMs can drive constant improvement over time.

Great PMs Value Preparation Above All

At highly-rated, Michelin star restaurants, there's a concept called ' Mise en Place' - roughly translating to 'Everything in Its Place.' It refers to the rigorously thought out organization of ingredients and tools needed in a busy kitchen, allowing all kitchen staff to operate as fast and as seamlessly as possible once they start cooking. In Patterson's experience, the best PMs perform their own 'Mise en Place' process before executing on products.

"Think about how complicated it is for kitchens to take hundreds of ingredients every day and combine them beautifully and consistently so that hot, gorgeous dishes all come out at the same time, every time for dozens of tables," he says. "This level of performance requires near perfection at high velocity. The process that diners actually see is just the assembly. All the real work was done starting in the morning before the doors open."

At a startup, the PM is the head chef, and the engineers are the individual cooks whose considerable talents and care create the ultimate product. In this environment, creating solid specs, furnishing resources when needed, and clearing pathways for productivity is the vital prep work. The best PMs focus their time and energy on this phase of the process.

Just like in kitchens, PMs need to anticipate and smooth out handoffs of work between people - engineers and designers, for example. There's very little margin for error. If one person falls behind, the entire 'kitchen' gets backed up. The more prepared you are for these scenarios, the easier it is to dig yourself out.

You want to create muscle memory for your team.

If your organization and prep are both strong, people will know exactly where to go for what they need, who to talk to for answers, where to get new data, how to handle issues that pop up. It will be the same and work every time. How can you promote muscle memory for engineers, the way you cooks have muscle memory for where to find a whisk or the salt.

Great PMs Are Their Very Best Under Pressure

In a restaurant, the cooking can't stop no matter what. If you're off the rails or backed up or ' in the weeds' as chefs call it, you have to get back on track without stopping or slowing down. In the military, you may find yourself in a position where your decision-making and execution are life or death for others. You can't crack or say you don't know. As a PM, you have a ship date, and the fate of your product or even your company depends on your ability to keep going no matter what.

In all of these situations, a leader needs almost robotic presence of mind, and it's ideally triggered when the heat is on.

It's that feeling of being 'zoned in' and the ability to see things in slow motion - so you can start pulling them apart and working the problem. You can get a bunch of people in a room and unemotionally make a list of what's going wrong, possible solutions, the tasks you need to get there, and who is going to handle them. It's the mindset that allows you to take a crisis and turn it into a checklist.

"For me, this definitely comes from the military and basic training," says Patterson. "For example, they put all this pressure on you around making your bed perfectly, shining your boots and all that - making you do jumping jacks in the bed you just made and then yelling at you because your bed is now messed up - and it sounds silly until you realize they're psychologically preparing you to be methodical under fire."

As first a PM and now CEO, this experience has made him preternaturally calm in stressful situations. "I'm able to detach because getting emotional or upset is only counter-productive," he says. "I'll tell people they did a good job after the fact, but during, it's all about getting it done. People see you as the leader and look to you for certainty. If you melt down, it's over."

War Room Product Management

Recently at Eaze, Patterson has combined all of the qualities above into a new approach for the whole company. They've created a War Room, transforming their largest conference room into a mission control center of sorts. Around the table sit single representatives from each internal team - product, engineering, operations, customer support, marketing etc. - everyone necessary to solve any problem. On the big screens at the front are dashboards showing the daily goal for deliveries plotted as an ascending curve, and how they're tracking so far (rendered as a real-time dotted line). The all-day objective is to stay above that line. If you do, you ' Win the Day.'

"We started with our long-term goals in terms of growth and operational efficiency, and where we want to be. We boiled those down into monthly goals - like we want to do X thousand deliveries this month," says Patterson. "Then we modeled literally day by day based on historical patterns - like higher demand on Fridays and Saturdays than Mondays and Tuesdays - to create a minute-by-minute daily goal."

The 'Win the Day' team staffs the War Room from 9 a.m. to 1 a.m. every day, but the members rotate. There will be a new ops specialist or engineer each day. But no matter where they rank on their own teams, the group in the War Room has the authority to make decisions in the moment. If deliveries start to track below the goal, they can choose to pull levers to lift that metric - like sending emails or offering discounts to generate demand. If a bug arises, they can all jump on fixing the issue and mitigating its impact at once.

If we win every day, we win the week. If we win the weeks, we win the month. If we win the months, we win the year.

"It's a military strategy, to get people in a room to facilitate fast, efficient communication and action," says Patterson. "It also exposes a range of people to this skill set, and connects them more immediately to how the company is doing and the operational side of our business."

Importantly, those in the War Room can call on and leverage their entire team behind them to help them problem-solve. You're allowed to raise hell if something's going to prevent us from winning the day, and whatever can be done to help becomes the priority. In this way, the 'Win the Day' strategy focuses the entire company around a shared goal. Everyone's activities in some way support and roll up to this one focal point.

In large part, the War Room concept was born out of the attributes Patterson believes make PMs great. It pulls the team toward a goal, rather than pushing them. Setting it up required a lot of thought, care and preparation so that individuals can act immediately, with muscle memory. It demands good judgment with limited data. And it teaches everyone who takes a seat how to react calmly and precisely at a moment's notice.

"In the military, they call the team at the front line the 'tip of the spear' but everyone behind them is the handle that's necessary to give them the support and force to be lethal," he says. "It's interesting to see this spear idea making everyone feel more connected to our customers and company goals. It's set off a whole cultural shift that's made us more deliberate and faster on our feet at the same time."
Art by Hero Images/Stone Collection/Getty Images.

# data[].attributes.attachment_link.title
Why Chefs and Soldiers Make the Best Product Managers

# data[].attributes.attachment_link.description
Five years ago, Clover Health COO Wilson Keenan got his first job in product management. Before that, he was a line cook. It wasn't his only work experience, but it's what stood out to the man who hired him, Jim Patterson - then Chief Product Officer at Yammer, now CEO of cannabis technology startup Eaze.

# data[].attributes.attachment_link.readable_text
Bringing it all together - an end to end example

Let's pretend you're an engineer, and your idiotic product manager wants you to stop playing ping pong and work on something of value to the business. Appalling, I know, but you grit your teeth and begrudgingly agree to do it.

You've had sprint planning, you've sized the work as a 1 or 2 and so you're comfortable with starting the work.

You're required to change the color of a button from red to blue. Hardly taxing, but always good to factor in a buffer when sizing.

What happens next? Here's a breakdown of what might happen. Note, these steps will be different for your product but should act as a guide:

1. Clone the repo

If you're a new engineer on the team, you might not have access to the codebase. If you don't, you'll need to clone the repo; that is, make a local copy of the repository on your machine which is cloned from the remote copy of the repo.

With a local copy of the repo cloned to my machine, you're ready to go.

2. Make the coding changes

Since this is a fairly straight forward front end task, you'll make the necessary changes. Changing button colors involves a few bits of CSS changes. Your CSS specifies the color blue at the moment, but your product manager wants to change it to red.

OK, here's the change:

That's your job done. In a few moments, you'll be done, but you need to sort out a few bits first.

3. Commit the changes

You've made the changes in the CSS, tested it in the browser and the color is indeed now blue, as per the spec. So you'll confidently commit your changes. To do this, you use the git commit command in your terminal to commit your changes.

git commit -a -m "Color changed from red to blue"

To ensure your fellow developers understand the nature of the change, you've included a helpful little message in your commit, which neatly summarises the nature of the change.

This has now committed the changes in your local repo.

4. Push the changes

The changes you've made are only made on your local machine, which means you need to push them. Using git push, you push your branch back to the origin repo:

git push origin [branch name]

5. Create a pull request

Before anything can be merged, you need to create a pull request - a request to pull your feature branch back into the master branch.

After you've pushed your code to the origin, you create a request to pull it back into master. This triggers a code review.

6. Review the code

The code changes you've created are reviewed by your fellow engineers to ensure your code meets the standards set by the team.

Since this is only a small change (changing the color of a button), it's likely that the code review process won't take too long.

With the code reviewed, you'll either get a thumbs up or a thumbs down from the team. If there's something wrong with your code you'll need to make some changes and push the new changes, if all is good, you'll be able to merge your code.

7. Merge the PR

You passed the code review. Congrats.

The last step is merging the feature branch back into the master branch. Before you do that, it's a good idea to make sure your local and remote repos are in sync. To do this, you pull the latest version to your local machine:

Then you can do your merge using something like this:

With the branches merged, the feature branch can be deleted since the code is now merged in the master branch and is no longer needed.

8. Deploy the release

With your code changed and the button updated, you may have additional sets of tests which run. For example, you may use a tool like jenkins which works as a continuous integration server which basically means it alerts the team to anyone who has added something into the code base that it doesn't like (because it breaks tests or is hideous).

With your build tests passing, the code is ready to be deployed and your button will be changed in the next release.

If you're lucky enough to have continuous deployments, that could mean a matter of minutes. If you're not, it'll be included in your next sprint.

What you need to know as a product manager

Git and GitHub is by no means an essential skill to have as a product manager. You will never need to use it in your day to day role, so having a deep understanding of git beyond what we've covered is a nice to have as opposed to a must-have.

From a product management perspective, it's useful to consider a few things in regards to git and GitHub:

1. Branching set up - If you're not sure what your branching strategy is for your product, spend a bit of time with your team to understand how a feature gets built, from a branching perspective. Does your team use feature branches, master branches, hotfix branches, release branches or something else? Knowing your branching set up can help you to empathise when things go wrong or when there are conflicts with merging.

2. Release processes - do you know how a release happens? Git and GitHub are linked to your release processes. If you haven't done so in the past, sit with your engineering team and watch how a release happens. If a release takes 2 days and 4 engineers, that's a problem - and you might want to factor in some time to deal with this into your roadmap. If you can get to a state of continuous deployment you'll be delighted with the improvements in speed you'll experience.

3. Devops - do you have a dedicated devops person in your engineering team? Git and GitHub is part of an overall devops set up and the goal of devops is ultimately to automate developer workflows. Having a team member dedicated to optimising developer workflows will help to ensure issues with merges and bugs on production get dealt with quickly and efficiently.

So that's it. Hopefully that's cleared up some of the questions you have around pull requests, merges, branching and all that other nonsense. Now get back to work, you lazy git.

# data[].attributes.attachment_link.title
GitHub Explained for Product Managers - Department of Product

# data[].attributes.attachment_link.description
Let's pretend you're an engineer, and your idiotic product manager wants you to stop playing ping pong and work on something of value to the business. Appalling, I know, but you grit your teeth and begrudgingly agree to do it.

# data[].attributes.attachment_link.description
Find templates for project plans, strategy, engineering and more... Browse through the largest collection of free templates for product managers, carefully curated by the FYI team.

# data[].attributes.attachment_link.readable_text
Product managers have to make many decisions every day, including product prioritization decisions, product design decisions, bug triage decisions, and many more. And the process by which a product manager makes such decisions can result either in an extremely well functioning team dynamic or... quite the opposite.
When it works well, the team feels as if the best ideas, regardless of where they came from, get implemented. They know their input will get heard. And they have a clear understanding of how and when decisions will be made. And even though the wrong decisions might sometimes be made, they know that when appropriate, they can and will be reversed. And while they may not always agree with the outcome of a decision, they trust in the team's ability to make the right call more often than not. And they believe the team can take on any challenge that might be put before them and solve it effectively.

On the other hand, when the decision making process is not working well, the team starts questioning a lot of the decisions being made. The team wonders whether the decisions were hastily made without taking into account all the relevant information. The team doesn't feel as if they understand how such decisions are made and may even believe the team suffers from hippo (highest paid person's opinion) decision-making. And they ultimately don't trust in the team's ability to make the right call.

The surprising thing about the difference between the well functioning team and the alternative is not the actual decisions being made, but the process and culture within which such decisions are made. To build the right decision making culture, I encourage product managers to follow the following best practices.

Establish your role as the curator, not the creator of great ideas
Great products are built by great teams and as such the best ideas can come from anyone on the team. It's important for your team to understand this and truly take it to heart. When your team believes that your role is to curate the best ideas and make sure they bubble up to the top, they'll be eager to participate in the process.

Make people's opinions feel heard
Once you establish your role, the most important thing to do is ensure people's opinions feel heard. This means making yourself accessible to hearing ideas from the team and taking the time to carefully consider them. Be careful not to immediately shoot down ideas you don't agree with. Instead try to understand their point of view and paraphrase their recommendation in your own words so they know that you've understood them.

Communicate the decision making process
When you are in the middle of making a critical decision, it's important to make sure the team understands the decision making process. If you're still in the phase of gathering potential recommendations, make that clear and solicit ideas from the team. If you waiting on additional information before making the call, it's important the team understands that as well so they know why a decision is taking additional time. And when the decision is eventually made, make it clear to the team what the decision is, the reasoning behind it, and that it's time to move on to the next challenge.

Favor decisions today over decisions tomorrow
The enemy of decision making is time. Decisions today can move the product forward today, versus decisions in the future simply slow down learning, cause people to wonder why it's taking so long, and reduce speed of execution. Therefore it's important to favor making the call today rather than later. Unless there is clear additional information you are waiting on before making a call, always favor just making the call right now.

Make the process for revisiting decisions clear
You'll inevitably end up in situations where you've made the wrong call and have to revisit a decision. It's important to allow yourself to do this, but at the same time establish a clear process for doing so. I like to always ask what new information is now known that is causing us to revisit the decision we made earlier? It's a great bar for ensuring that decisions are not constantly being revisited and flip-flopped, yet ensuring there is a mechanism for changing course when appropriate.

With these five best practices, you are on your way to establishing the right decision making culture on your team to ensure an extremely well functioning team dynamic.

# data[].attributes.attachment_link.title
The Art of Decision Making as a Product Manager

# data[].attributes.attachment_link.description
Product managers have to make many decisions every day, including product prioritization decisions, product design decisions, bug triage decisions, and many more. And the process by which a product manager makes such decisions can result either in an extremely well functioning team dynamic or... quite the opposite.

# data[].attributes.attachment_link.readable_text
Welcome to the cutting edge of computer programming. A great place to start? Our Machine Learning Crash Course (MLCC). Once you have the basics down, ramp up your skills by applying ML techniques to big datasets in real-world competitions. Other paths take you further into data science, and innovative ML approaches like deep learning and neural networks.

# data[].attributes.attachment_link.title
Machine Learning - Google Tech Dev Guide

# data[].attributes.attachment_link.description
Are you ready to move beyond traditional programming and explore the world of machine learning? Start here with Google's crash course, then move on to further resources on data science, neural networks, and deep learning. Once you have confidence in your ML toolkit, you can practice with real world problems in Kaggle competitions.

# data[].attributes.attachment_link.readable_text
In this course, you'll learn to approach an interview as a showcase, not as a test. You'll see why it's critical to prepare through practice, not memorization. Experienced instructors will help you learn to avoid common interview pitfalls. Finally, you'll practice what you've learned in mock interviews. Your ultimate goal is to go beyond just showcasing your understanding. You want to show how you think through a problem, and come to a solution. Are you ready to ace your next interview?

# data[].attributes.attachment_link.title
Machine Learning Interview Preparation | Udacity Free Courses

# data[].attributes.attachment_link.description
In this course, you'll learn to approach an interview as a showcase, not as a test. You'll see why it's critical to prepare through practice, not memorization. Experienced instructors will help you learn to avoid common interview pitfalls. Finally, you'll practice what you've learned in mock interviews.

# data[].attributes.attachment_link.title
Learn Python, Data Viz, Pandas & More | Tutorials | Kaggle

# data[].attributes.attachment_link.description
Practical data skills you can apply immediately: that's what you'll learn in these free micro-courses. They're the fastest (and most fun) way to become a data scientist or improve your current skills.

# data[].attributes.attachment_link.readable_text
Tutorials on the scientific Python ecosystem: a quick introduction to central tools and techniques. The different chapters each correspond to a 1 to 2 hours course with increasing level of expertise, from beginner to expert.

Release: 2020.2

# data[].attributes.attachment_link.title
Scipy Lecture Notes - Scipy lecture notes

# data[].attributes.attachment_link.description
Tutorials on the scientific Python ecosystem: a quick introduction to central tools and techniques. The different chapters each correspond to a 1 to 2 hours course with increasing level of expertise, from beginner to expert. Release: 2020.2