CHAPTER 8

Partner with Engineering

Build trusted relationships and execute smoothly in collaboration with your primary stakeholder.

Product Managers and Engineers Work as One Team

Do not see it as your role to drive engineering to execute against a given product plan. Your role is to partner with engineering. You effectively work as one team with complementary goals, collaborating on and having influence over each other’s areas of responsibility to produce the best results.

In your partner role, it will be beneficial to do the following:

•   Communicate the overall goals and vision—Help the team understand and be motivated to achieve the product’s goals. Provide supporting business and customer context to show why something is important.

•   Encourage ownership—Welcome the team to contribute ideas, solutions, or viable trade-offs. Let engineering take responsibility for making commitments. You should support investment in quality and process improvement, and invite input on the product direction.

•   Define, clarify, and prioritize requirements—Ensure the team is “unblocked,” knows what the most critical needs are, and has all the information required to do the necessary work.

•   Own stakeholder feedback and communication—Provide air cover and identify and prepare for changes or potential disruptions. Enable focus by owning the resolution of issues. And don’t become a source of ever-changing requests yourself.

Achieving these outcomes is a group effort, variously involving engineering management, Scrum masters or project managers, and experienced lead engineers. You should understand the structure of the engineering team and the product development process, and determine how and at what points you can play a role in empowering engineering.

In this chapter, I don’t intend to provide detailed definitions of the different development processes used in modern software organizations. Some of the principles discussed are drawn from a set of methodologies known as Agile, and Scrum in particular. These are interesting both because of their popularity within modern technology organizations and because they imbue the values of collaboration, openness, and flexibility essential to the success of any high-performing team. Additionally, they can generally be applied in almost any environment.

For further reading on the mechanics of common development models such as Waterfall or iterative development methods (and notably Scrum), refer to the online supporting materials at http://www.influentialpm.com.

Understanding Roles and Responsibilities

It is critical to establish and understand what you are responsible for and which responsibilities fall on your engineering team. You must also know what the engineering team is dependent on you for and which engineering decisions require your consultation, which ones you need only be informed about, and which ones you should rarely be involved in.

Failure to clearly understand responsibilities leads to two undesirable situations:

1.  You frustrate your team by becoming overly involved in technical decisions, being prescriptive on features but lacking in context, interfering in execution details, or driving them toward deadlines.

2.  Gaps emerge. Your engineering team does not receive what is expected from you (such as context, data, specifications, stakeholder buy-in, and quick trade-off decisions).

Engineering organizations come in many configurations and specialized roles. Names of roles or job positions that you hear thrown around might include front-end engineer, web developer, full-stack engineer, quality assurance, data scientist or analyst, and project manager. Rather than attempt to define each role, which would be a challenge given the variance across the industry, in addition to the product manager, I will identify two general roles and their primary responsibilities:

•   The project manager—Sometimes also called the Scrum master, execution lead, or program manager. While this is often a separate role, project execution is sometimes managed by an experienced senior engineering leader instead (but not the product manager).

•   The development team—Brings collective technical expertise to tackle difficult and meaningful customer and business challenges.

Table 8.1 contains examples of the key responsibilities for each role during the implementation/execution phase—which are subject to change given your unique environment and culture. As you review each responsibility line by line, you may notice how each is interdependent and essential to the success of the other team members.

A product manager must not double-hat as project manager for two primary reasons:

1.  Conflict of interest—A product manager’s incentive is to deliver maximum business value. He or she will encourage teams to be aggressive on commitments and have strong points of view about how to implement feature specifics. There is nothing inherently wrong with that, but, conversely, the project manager and engineering lead need to protect the team from an assertive product manager. When product managers attempt to perform both roles simultaneously, they may steamroll everyone into agreeing to a plan they do not believe in, disempowering and discouraging them. Negotiating with oneself is hard to do.

2.  Strategy versus execution—The product manager owns the customer understanding, identification, and scoping of new needs, along with prioritization of the product backlog. He or she must think ahead of the team to plan, prepare, and validate future work. If too caught up in the day-to-day management, the product manager won’t spend enough time with customers or stakeholders and won’t prepare for the future with enough rigor. When the time for the next initiative arrives, the product manager can be left scrambling to define sufficient work for the team to complete or provide only vaguely thought-through requirements.

In summary, allocated responsibilities establish a deliberately healthy tension between engineering and product management. Product managers are responsible for identifying, defining, and facilitating new opportunities for the business. They want to deliver on more of these opportunities and do so quickly. Engineers need both to build new systems and maintain existing ones within real-world technical constraints. They want to do so efficiently and in a high-quality way—which may slow delivery initially but will provide greater flexibility and scalability in the long run. Engineers hate coding things twice.

You can’t remove the inherent tension between these different roles and incentives. You can, however, negotiate the tension from a position of shared understanding and mutual trust and respect.

How to Build (or Lose) Strong Engineering Relationships

Your relationship with engineering is the most crucial to your success. In Chapter 2, I discussed techniques for leading through influence. Extensively use the approaches outlined there to be an effective team member. Engineering will often know the product, business, and customer needs as well as you do, and it deserves a say in product direction, priorities, and solutions.

Engineers, as a rule, are incredibly rational, intelligent, and outcome-oriented. They demand efficient use of their time and talents. They want to have an impact on the business and expect you to provide the data to justify your recommendations and measure the success of initiatives objectively.

You’ll lose credibility by wasting their time on a project that never sees the light of day or fails due to lack of customer validation and internal collaboration. However, if you involve them on each step of the journey, they will help you create better solutions and mitigate risks, and they will be your advocates—even if a project does not succeed from time to time.

Build strong relationships and maintain respect with your engineering partners by employing the following techniques.

1. Embrace Five Core Teamwork Values

It is essential as a product manager that you see yourself and engineering as “one team,” where you frequently collaborate with designers and developers. Operating as one team breaks down silos and creates a feeling of joint accountability—reducing the likelihood of finger-pointing when things don’t go as well as hoped. Don’t merely deliver requirements and ask for a set of designs, a plan, and a timeline. This is known as “throwing over the wall,” and that’s just what your team will want to do to you.

To make cross-functional teams effective, you need to embrace five powerful teamwork values. While these values are explicitly stated as part of Scrum, I have found them to be essential values in any environment. Exhibit these behaviors and lead by example.

1.  Courage—Work through challenges together so that the team can achieve the right goals. Constructive conflict is essential to finding the optimal compromise and best outcome that balances customer needs, simplicity and efficiency, and technical and resourcing constraints. Differences in opinion must be embraced and objectively debated. Keep discussion grounded in fact and rationale, and never get personal.

2.  Focus—Strive toward a single (or few) goals at a time, to produce excellent work and deliver value sooner. Context-switching kills productivity, frustrates the team, and puts commitments at risk. This is particularly true for engineers as they solve intricate technical issues that require deep concentration. While you may not be able to control all distractions, don’t make a habit of becoming one yourself.

3.  Commitment—Autonomously, collectively, and universally commit to scope and timelines, and strive to achieve them. Doing so, even for well-understood scope, is uncomfortable—there are always the unpredictable disruptions you could not foresee. Nonetheless, strive to deliver, even if that means working a little longer or harder.

4.  Respect—Have trust and belief in team members, knowing that you are all technically and intellectually capable, and working with good intent. There should be no blame, no politics, no judging, and no undermining. Team members will double their efforts when working alongside someone they trust and enjoy being around. You don’t need to be best of friends; but mutual respect for others’ contributions goes a long way.

5.  Openness—Be transparent with stakeholders and each other about the status, timeliness, and quality of the work. No one likes to disappoint, but communicating issues early on increases the chance you’ll receive help. Likewise, when things are going well, openly celebrate each other’s contribution.

 

2. Start Off Right and Spend Time Together

When the team is first constituted (or when new team members join) explicitly discuss ways of working together. Topics to cover include the following:

•   Roles and responsibilities—In Table 8.1, I summarize high-level responsibilities for product managers, project managers, and the development team.

Explicitly discuss, adapt and adopt these frameworks to establish soft boundaries that welcome contribution yet clearly define the responsible party. Without accountability, certain activities can fall through the gaps, or you may step on each other’s toes. It can lead to confusion, mistrust, and scapegoating.

•   Managing distractions and interruptions—Engineers require extensive unbroken time to work on challenging problems and avoid context-switching. Find out what time periods they feel they work most effectively in and minimize disruptions during those times so they can focus. Also agree on what constitutes a necessary disruption and what doesn’t. Answering non-blocking questions may not qualify but dealing with a high-priority emergency clearly would.

•   Meetings—Understandably, engineers loathe poorly run, ineffective meetings especially if they are scheduled with little notice or interrupt a productive problem-solving session.

Do not calendar a meeting to solve every issue or to extract status updates from the team. Instead, win their trust by limiting their involvement to a few high-impact forums, held regularly (the same time each day or each week). Plan your meetings well and run them efficiently to produce meaningful and clear-cut decisions.

•   Communication preferences—In general, since engineers spend much of their time on computers, they may prefer to use email, instant or group messaging (such as Slack), wikis, and ticket-management systems (such as JIRA) to pose and receive answers to questions from you.

Agree upon minimum turnaround times for inquiries among team members. A courteous reply within 24 hours, even if an issue will require longer to address, signals that the receiver is working on it.

Nonetheless, do not forget that in-person interaction in addition to electronic communication is essential to tackle more complex issues, to avoid back-and-forth, and to build deeper personal relationships.

•   Feedback—Discuss how to give each other feedback (there are many frameworks you can find online). Always ask first if the other person is receptive to the feedback (“Can I give you some feedback?”) and focus on specific facts and behaviors, not the person. The very act of highlighting a norm for feedback is permission to give and—importantly—receive feedback openly.

When conflict gets heated, give each other time to disengage but do not leave interpersonal issues brewing for long.

•   One-on-ones—Schedule some time weekly with key engineering leads and engineering managers. Discuss work but don’t make it all about work or a status update. Also schedule time (less frequently) with each of your team contributors, regardless of whether they are leads. Perhaps meet over lunch to keep it informal.

When meeting a team member one on one for the first time, ask genuine questions about them—ask about their background and family, professional history, what brought them to the company, and personal interests. And share something about yourself. Not all people are forthcoming with personal stories (so don’t interrogate), but the act of showing interest in others is a powerful trust builder.

•   Collocation—Have product, design, and engineering located in close physical proximity if possible. Informal interactions are critical to building trust. Relying on tickets, documentation, and email—punctuated with your regular meetings—might get the job done, but it can slow the pace of iteration and lose opportunities to build trust. When you don’t work closely with your team on a daily basis, assumptions take the place of explicit communication. Conflict can develop, with each team erring on the side of “bad intent.” The “us” versus “them” mentality takes root. Team members not part of recent discussions fall behind in having a shared understanding of current challenges and their status.

In today’s technology environment, however, collocation can often be an unreasonable expectation. Commonly, teams are now partially co-located, with some remote members or outsourced third-party development providers. Some companies are 100 percent remote or work-from-home. Hiring large numbers of engineers in one location may be a recruitment and retention challenge. Costs may be prohibitive when hiring talent in competitive markets. And companies that can tap into a vast array of skills, cultures, industry backgrounds, and problem-solving approaches have significant advantages.

Differences in time zone, language, work styles, comfort with conflict, and a lack of face-to-face time (needed to help create trust) all undermine team effectiveness. To compensate, you may need to apply extra structure and put more effort into communication.

3. Involve Engineering Early—Appropriately, Not Excessively

Find a balance between collaborating with and distracting engineering. There is a huge difference between asking them to “do your job for you” and involving them early and sufficiently to understand the priorities and contribute solutions. Engage them too late and you risk ending up with a less-than-satisfactory solution that is also difficult to engineer.

Consider it your role to create the environment in which a team can start to solve a well-understood problem. Essentially, you must do the following:

•   Establish shared goals—Establish goals that drive customer and business outcomes. Without these, your team will be rudderless (perhaps even resistant) and confused as to whether their work is a valuable contribution.

•   Set context—Complete necessary data analysis, specifications, and customer validation, so that you know all you need to know to justify why the problem is worth solving at this time.

•   Prioritize the work—Break down requirements, elaborating on details where useful—but not excessively so—and have a point of view on the order of execution (ideally as a groomed, force-ranked product backlog [see Chapter 7]).

•   Align stakeholders—Ensure your project has broad support and that stakeholders’ concerns are addressed so you can preempt later distractions.

You must do some of this heavy lifting before involving much of engineering’s time. However, never leave it till the end. Instead, do this:

•   Openly discuss business and customer goals early and frequently. Talk about the high-level business metrics for the project as well as the metrics for which you and your team will be accountable.

•   Share early drafts of hypotheses, data, specifications, conceptual designs, and potential solutions. The more context, the better.

•   Invite engineers to customer interviews and share summaries of what you’ve discovered so they can understand the issues firsthand.

•   Generate ideas together—with regular jointly held brainstorms, for instance—and support their sharing of technical concerns and limitations.

•   Encourage the review of initial designs and requirements. You should start making trade-offs early so that development is easier and user experience remains of high quality.

Be open to your engineering team challenging you at all stages of the product lifecycle: the validity of your data and hypotheses, your planning and strategy, and the content and priority of detailed requirements. Do not dismiss their ideas just because you already have something in mind or have already invested much time going down a certain path. And never present engineering with rigid, detailed product designs as “your” vision for implementation.

Proactively seek their involvement. Capture and document their input and demonstrate your interest in addressing and incorporating their recommendations. If none are forthcoming, do not assume there are no problems—you may need to be doing more to get busy engineers to engage.

With a firm grasp of the goals and supporting data, engineers are particularly interested in ideation and solution generation. In addition to having whole new ideas, they can spot opportunities to offer useful functionality by leveraging existing technologies that save engineering effort. They can research and find new technologies to integrate into the technology stack, not only to solve a specific issue but also, perhaps, to add new functionality.

Engineers also need to start thinking about the feasibility of solutions well in advance. Often, you’ll ask them to build capabilities that push the limits of the stack or provide new core functionality. Engineers are good at abstracting the underlying systems required from user interfaces and high-level requirements, spotting patterns for efficiencies and opportunities to reuse existing code, perhaps avoiding some steps completely.

Share designs and emerging requirements early to allow them to start thinking about these opportunities. Encourage them to suggest new approaches to problems that will be more feasible—this speeds time-to-market while making the system easier to maintain and the team happier.

Mutually determine when deliverables are sufficiently fleshed out to start development work. A lack of alignment on the completeness and depth required for specifications documents, product backlogs, user stories (especially acceptance criteria), and analysis is a frequent point of contention between engineering and product. What you later assume to be refining and adding detail, engineering may claim to be scope creep.

Finally, be cautious not to overstate your expected outcomes in superfluous terms, in the hope that you will motivate them. You will quickly lose credibility if the promised benefits do not materialize. Instead, discuss the business goals, show them your data, and talk honestly about the risks. Engineers are problem-solvers at heart and enjoy a challenge.

4. Engineering Doesn’t Work for You

One of the greatest, yet entirely avoidable, reasons for unproductive conflict is your attitude (whether intended or not) toward the role of engineering. You will quickly earn their ire if you see them as a service organization or as “order-takers,” who must execute on your predefined plan.

Context is everything. Share your analysis and rationale openly. Engineering wants to understand and influence the reasoning behind why the project is a priority right now and how it will further the business and customer’s goals. They have every right to know why their hard-spent hours will contribute. Sometimes a project’s scope or deadline is non-negotiable, highly-constrained, or urgent for valid business reasons. In these instances, you must still help engineers understand what’s driving the need and give them any possible opportunity for a say in the direction.

Establishing estimates is a particularly sensitive subject. Focusing only on setting a deadline, especially with scant scope definition, drives an engineering team nuts—and before too long, they will expect you to deliver highly detailed, “locked-down” specifications before they even consider estimation. Early in a project stick to high-level T-shirt-sizing or relative-estimation methods.

Once a project is underway and the scope is better understood, though, it is reasonable to ask for and expect engineering tasks to be specified and estimated—but know that these can change for reasons outside everyone’s control. Understand the root causes for a change and seek to support the team in revising estimates—and if these have high visibility, communicate the changes widely.

Understand the construction of your technology system, at least abstractly. Ask your team to map out the overall architecture, especially the more challenging areas to engineer. By increasing your knowledge of how things work, you will get a feel for the complexity of your requests. You will build empathy and become better positioned to inform trade-offs in implementation. It can also help you hold your own when engineering tells you that something is impossible—you will appreciate their constraints yet also be able to critique their approaches and suggest workarounds.

However, be judicious in setting your priorities based purely on how hard you think it will be to build the product. While this is a factor to consider in prioritization, doing the most valuable things first will usually deliver more benefit to your organization than focusing on many smaller, incremental features of marginal benefit, simply because they are deemed “easier.” Engineers like a challenge, and they like their efforts to have an impact!

Micromanagement is an unpleasant trait in a product manager—following up on tasks repeatedly (“When will they be ready?”) or asking for too much detail about implementation (“How are things being built?”). Driving accountability and predictability are key, but it is essential you have a strong project or engineering lead to manage and track execution tasks. Then you can then dedicate your time “outward”—on ensuring stakeholder buy-in, collaborating on trade-offs, and thinking strategically about what comes next—rather than “inward,” on the day-to-day running of the implementation team.

Occasionally you might need to push engineering, such as when you need them to hit an original high-stakes deadline or when the team is repeatedly missing targets. If you have invested in your relationships up front, then holding engineering to a deadline is easier. But seek to understand the complexities before pushing—if a significant issue has arisen, it makes no sense to expect the impossible. If it’s within reach, however, gently push and remind the team of the goal.

5. Hold Yourselves Mutually Accountable—and Admit Your Mistakes

It happens. Requirements change. Features fail. You miss something. Your customers and business needs must come first—and this may require fast-tracking, redoing, or abandoning a project. Changes can seem simple to you, but they may require a wholesale overhaul for the developers. If you do not own up to your mistakes—regardless of how well-intentioned you were or whether the changes were outside your control—you will frustrate your team and quickly lose their respect. Apologize sincerely and don’t blame others or make excuses.

Be decisive—if you’re not, your engineers can’t make progress, and they may end up having to make less-efficient technology choices. It is often better to make a call and move on, acknowledging the risk, and then admit a mistake later.

Engineers love working with other high performers. Laziness; failure to follow through (saying what you’ll do and when, but not delivering); or the tendency to give incomplete or inconsistent specifications, to leave assumptions unchallenged, and to politick—all are anathemas to most developers.

Having high standards for your own work earns you the right to challenge engineers when their work isn’t up to expected quality. Work with your technical leads when a team member appears to have an attitude problem or is missing commitments (perhaps refusing to make them). Engineering management will respond by getting that person help or setting specific expectations. And, in time, with strong enough relationships, you should be able to provide (and receive) feedback directly.

When something goes wrong in execution, encourage the team to continually learn from their mistakes—through regular retrospectives or five-whys. Missed deadlines, quality issues, misaligned scope expectations—all are common and best seen as opportunities to learn and grow.

You can find a five-whys template and example online at http://www.influentialpm.com.

Key Execution Phases—and How You Can Contribute to Make These a Success

Generally—regardless of your specific development process—any initiative moves through four broad steps to completion (as illustrated in Figure 8.1):

1.  Planning and kick-off—Establish the context, supporting data, and goal. Introduce the scope, requirements, and known issues. Determine the engineering plan, resourcing, timeline, and next steps.

2.  Implementation and check-in—You will spend most of your time in this phase. The project is taking shape at this point, and you are facing and addressing challenges. The team frequently checks in on progress, helps remove blockers, and shares information. Otherwise, the project could stall or head off in an undesirable direction.

3.  Product review—You can demonstrate partially or fully working features, and inspect how complete the product is to specifications. You can validate whether it meets the needs of your target market and give stakeholders the opportunity to provide feedback.

4.  Retrospective or post-mortem—Each cycle provides an opportunity for the team to identify what went well and what they can do better. Regularly review your process to determine ways to work more productively, avoiding unresolved issues that may become contentious.

Using iterative development methods, you can continuously cycle through these steps (in Scrum, a two-week cycle is not uncommon). While more traditional projects may take months to complete and include formal gates or milestones along the way, the principles remain the same.

1. Planning and Kick-Off

As product manager, it is your responsibility to own the following:

•   Prepare and share—Before kick-off begins, you must have completed customer research, data collection and analysis, and prioritization and justification, and you must have gotten stakeholder buy-in. You will have a detailed, fleshed-out specification (Chapter 6) and a groomed backlog (Chapter 7)—and if you don’t, do not expect to get much further.

Encourage engineering to actively review upcoming specifications and draft designs and to ask questions. Initiate the process with some one-on-ones with key developers, to preview the plan and unearth their concerns in advance.

•   Hold a kick-off meeting—Getting the whole team around a new initiative together can be immensely energizing. A kick-off allows you and your team to start strong—with a common understanding of the “why”—and to identify issues and dissenting opinions early. Your goal is to ensure everyone is on the same page, in agreement that the proposed initiative is the right one for right now.

Prepare a brief kick-off document that includes the following:

   A refresher of your product vision, roadmap and key metrics;

   The project goal and hypothesis of desired outcomes;

   Quantitative and qualitative supporting data, especially of the customers’ needs;

   An explanation of how the project will map back to company priorities and KPIs;

   An explanation of how it was prioritized over other potential initiatives;

   Known issues, risks, and constraints;

   Highlights from your product specification. Address emerging comments and questions, and encourage more.

An example kick-off template is included at http://www.influentialpm.com.

Don’t just present information to your team—facilitate a conversation. Listen and allow them to raise concerns. An excellent technique to make sure your kick-off stays on track is the “parking lot”—a whiteboard list of items you commit to coming back to resolve at a later date. At the end of the kick-off, create an action plan and immediately follow up on any blocking items to keep up the momentum.

•   Support the engineering planning process—Whether you use Scrum to break down user stories into tasks for rough estimates, or a formal analysis for technical specification and timelines, it is essential the team has a sense of ownership and control over their commitments.

Your role is to answer questions, or find answers, rapidly. Understand the technology challenges and encourage the team to suggest solution alternatives if this might accelerate the timeline, improve quality, or reduce complexity.

You share so much information during planning. Capture the details—summarize conversations, decisions, and outstanding issues in the appropriate place within the product backlog, specification document, or team wiki. If you observe team members taking notes, ask them to incorporate them or to send them to you to add them.

A common problem during planning is to underestimate the work required for full testing and validation. Ensure the team is considering sufficient time to write unit tests, validate, and debug code.

•   Respect but push on commitments—Product managers are in a tight spot. They are accountable for shipping product of value to customers, yet they rely on the development team to deliver it. However, if they try to push too hard, morale drops and teams lose their sense of ownership. You may well find less being achieved, not more.

You should, though, encourage the team to work outside its comfort zone—to practice courage and commit to more than they know how to deliver (or even despite whether they can deliver). In a high-functioning team, everyone understands the desire to achieve more and take greater risks. They’re working hard and will push back when enough is enough.

2. Implementation and Check-In

Once an initiative is underway, your engineering team will take the lead. You will make yourself available to respond quickly to questions as they arise and keep them on track by blocking and tackling issues.

•   Overcommunicate—You want to know the state of implementation without always checking in on status. Mature organizations will have a well-documented development process and formal meetings in which information is shared and artifacts (such as timeline and resources) are reviewed. You should actively participate in established forums but also augment these discussions with informal channels to deal with smaller issues.

At the other extreme, if your team is small and co-located and you are in a high-trust environment, you might share information informally more often. This can be the broadest and quickest way to resolve issues, but it is usually insufficient as decisions are often made in silos that omit some stakeholders.

In either case, err on the side of overcommunication:

   For decisions made in informal interactions, capture a note and place it in your backlog, tickets, or team wiki. Follow up with an email to a broader audience if necessary.

   Negotiate access to timelines, sprint backlogs, burn-down charts, and other project management artifacts. Frequently review and keep an eye on issues you might be able to unblock (such as an open question or stalled ticket). Do not, however, follow up on details incessantly.

   Ask to be tagged on tickets relevant to your project, so status updates and comments are pushed into your inbox. Ensure rapid response if tagged to encourage continuation.

   Working through engineering leads and project managers, ask them to bubble up issues and information from the rest of the team.

   If finding blocks of time to problem-solve together is challenging, suggest scheduling “open hours”—a time when you will mutually be available if needed.

   Offer to take ownership for updating stakeholders with progress and blockers. If this is explicitly agreed upon to be part of your role, you have an excellent reason for gathering information from the team on a regular (but not too frequent) basis. Keep yourself informed and keep stakeholders in the loop, giving the team air cover. (See more in Chapter 2.)

•   Hold lightweight check-ins—Engineering is a highly complex activity requiring deep concentration. Context-switches, interruptions, frequent breaks, and urgent emails are highly disruptive. Nonetheless, issue identification, resolution, and status updates are important.

To balance these competing needs, establish a regular “stand-up.” Borrowed from Scrum, the stand-up is a place to share recent accomplishments, affirm upcoming goals and activities, and surface emerging issues. Depending on your team’s velocity and the rate at which problems arise, you might require check-ins daily, every other day, or weekly. The longer the cycle, the higher the risk you leave issues unresolved.

Don’t delay holding the first stand-up too long after kick-off, since this is your chance to ensure the team has started strong and is aligned.

Ideally, hold stand-ups in the same place, so everyone gets in a routine. Literally standing up is customary. Keep it short—15 minutes should be sufficient. Avoid gathering in a meeting room where you’re inclined to get comfortable and take time to small-talk, set up, and wait for others to arrive. Don’t prepare documents—stick to artifacts you already have. Ideally, an engineering lead or project manager (or Scrum master)—not the product manager—runs the meeting.

All team members must be on time and attend in person (unless they are remotely located, and then they should join via video conference, not phone to ensure full engagement and “facetime”). If many members of your team are remote, then hold the entire stand-up over a group video conference, with everyone joining from their desk.

The format is simple—each member of the team has a turn at answering three questions:

Team members are expected to be transparent and share good and bad news. If, for some reason, a member of the team has not been able to complete something they committed to or is stuck in any way, they should volunteer the information. If a team member isn’t forthcoming for some reason, others are expected to ensure the three questions are asked and answered by everyone.

The stand-up is not a place to resolve issues or to ask or answer questions outside these three. If there are impediments, team members agree on who will be responsible for follow-up. Usually, this is a smaller subset of the team and, if it is a severe blocker, they meet immediately afterward.

Apart from providing their own updates, the product manager’s primary responsibility in stand-ups is to observe and identify common issues. These can then be taken “offline” for further exploration with the project manager or engineering team. Here are some good questions to ask yourself:

   Is the project moving at a pace where I can see it coming together?

   Are team members marking work as “done” or “code complete,” but issues such as bugs or unfinished testing remain open?

   Has the team worked on what they promised to in the last stand-up?

   Is what the team is working on next aligned with my project’s priorities? Or are they working on something for someone else?

   Do I hear the same tasks come up again and again? Does that suggest something is stuck?

   Are any impediments related to the clarity of requirements? How can I assist? How can I do better next time?

   Are impediments addressed within a day or so? (If the problem is still being talked about at the next stand-up, there may be a more significant issue.)

   Are potential issues not being raised? (Be on the lookout for body language or a quiet team member.)

   Do I see a sense of urgency and engagement? What can I do to encourage and motivate?

•   Be prepared to make trade-offs—You need to have a practical mindset. As details surface the full complexity of implementation will become apparent to the development team, and they may request to compromise on designs or features to make engineering easier. Listen to the technical explanation behind the request and brainstorm options for workarounds. You don’t have to agree on the spot—take responsibility for gathering data to ensure the alternative will work for the user and business, and return with an answer as quickly as you can.

As covered in Chapter 9, scope, timeline, and quality are often at odds. Engineering owns quality, and quality should not be easily sacrificed, or you’ll quickly earn an undesirable reputation.

If you dig in your heels every time a trade-off is needed, you’ll add risk to your project and earn a reputation for being unreasonable. But neither should you agree to every tradeoff. Shortcuts are okay but not when they grossly impact user experience or value.

•   Block and tackle—Yes, it is your job to provide air cover for your team, even if that means more pain and work for you. You want them focused on solving difficult technology challenges to drive success for your customers and your business. Stakeholders who go “directly” to engineering with requests, feedback, or distractions not only disrupt your project but can result in your team suddenly working on projects other than yours. And you may be seen as someone who doesn’t do enough to avoid distractions.

Especially if you’re a more junior member of the company, it can be nerve-racking to try to redirect a senior stakeholder. As always, an objective and flexible approach works best:

   First, seek to understand. Ask open-ended questions. What is the underlying cause or context for the disruption? (Try the five-whys from Chapter 4.)

   Reiterate how your initiative benefits the business and why it was a priority in the first place. Share context and data. Explain how the disruption added risk or extended the timeline.

   Sometimes the disruption is more important, enough to force a reprioritization—in that case, make implicit trade-offs explicit. Inform the stakeholder of the impact, accept the change, and communicate it to the team.

   If you think you can identify one, offer to help find an alternative path to address the need that is prompting the disruption. You don’t need to generate solutions on the spot—promise to return with options by a specific timeline.

   Ask that the stakeholder work through you if anything comes up in the future, rather than go direct to the development team. Tell them you’ll either identify a workaround or offer trade-off options with estimated impact while keeping the team focused on agreed-upon goals.

If needed, ask your manager for help or approach the stakeholder jointly with the engineering lead and project manager.

If the issue appears to be endemic, track the cumulative impact so you can escalate it and negotiate time and resources for your team to complete their work. Your team will be frustrated if held to its commitments despite disruptions. Help them avoid this.

•   Motivate the team—Little things matter in keeping your team excited, engaged, and productive. Reinforce goals and context to keep the “why” top-of-mind. Share any good news from customer validation or stakeholder updates. Bring in cupcakes or spring a round of beers at a happy hour. Ask the company to support the purchase of T-shirts with a fun design. Celebrate team achievements. Thank them sincerely. It is easy to lose sight of the little things that matter when everyone is heads-down.

3. Product Review

Regularly review the cumulative results of the team’s work with stakeholders, to keep them informed and aligned. Showing a partially working product early, to get addressable feedback or to surface misunderstandings, is preferable to waiting until you have a fully working product that may not meet expectations. A scheduled review (or demo)—say, every two weeks—ensures that a long period of time will not lapse between gathering stakeholder feedback. It also provides an excellent opportunity to reinforce the project’s business importance and validate progress toward specifications.

It is good form for the product manager to allow the team to shine and let individual engineers demo their work. It helps the team be more visible, motivated, and accountable. Even though not all team members are polished presenters, it is more valuable to work through that awkwardness than have one person dominating the limelight.

Reviews can be frequent (such as at the end of each sprint if you are using Scrum) or on an ad-hoc—but not infrequent—basis when implementation reaches key milestones. Make this one of a few more substantial meetings, which all engineering, design, and product contributors attend, along with internal stakeholders who are interested in the product. Prepare well, so you are set up for success.

•   Secure buy-in—Certain attendees may be prone to derail progress or bring up unrelated issues (such as revisiting prioritization decisions or business goals). Or you may know that the product demo won’t be as polished or as complete as a specific stakeholder might expect. In either event, seek buy-in ahead of time. Remind them of the purpose of the review, give them a preview of what is to come, and ask them to bring up concerns with you directly now (rather than during the review when it may deflate a hardworking team).

If helpful, recruit a stakeholder to send a message or reiterate a point during the review that you have been making. This is particularly useful if your team needs to hear from someone other than you (for example, if the team appears to lack a sense of urgency).

Prep stakeholders to emphasize the importance of the work the team is doing and the impact on customers and the business. Have them call out names and specific achievements. It is a huge morale boost for the team to know that senior stakeholders value their work.

•   Schedule and validate demos—In collaboration with engineering leads, assign a presenter to each part of the demo and ask them to prepare (or script) it. Ensure the demo is fully working—demos tend to be on development servers, which might not work according to plan in the review. Time everything to run for no more than an hour, including an allowance for open discussion. Suggest they do a dry-run for any team member new to this. To avoid unnecessary busywork, make sure there is no slideware—but only a working product.

What can be demoed is sometimes not obvious—it doesn’t all have to be compelling user-ready features. Engineering can show small increments of work such as a command-line script or function, API input/output, or a rudimentary UI or manipulation of data. Even infrastructure work can be demonstrated (for example, ask, How can you show me that the storage upgrade has been successful?).

•   Structure and guide the demo—Remind all present of the purpose of a demo and (if necessary) what they can expect and the groundrules for how you would like stakeholders to engage with you and the team. Reinforce the project goal and remind everyone that the project is in progress (since what they will see is likely to be incomplete). Ensure the review, though, does not turn into a status discussion.

Step back and let team members take you through their sections in turn. It is okay if the demo isn’t polished, particularly early in development. Have them talk through what a rough design, a prototype, or the code does, so stakeholders can follow along.

If a team member skips over important context during their demo and stakeholders appear lost, ask the presenter for clarification in the form of a question (resist the urge to state it for them). For example, “When you clicked on Submit, where did the data go and what happened next?” If something goes wrong in showing the demo, acknowledge it, make a note, and keep moving.

Invite feedback from stakeholders by asking them questions. Avoid getting defensive or explaining away limitations. Stakeholders can sometimes be overly critical. Probe for understanding—having them share the underlying business context is more valuable than just reacting to a feature. It helps everyone make better decisions in the future. If something comes up that isn’t immediately relevant, listen for a bit to confirm your suspicions and then respond with “Great question—can you and I take that offline?” (and follow up afterward).

Don’t forget that internal stakeholders are not customers, so don’t take to heart every piece of stakeholder feedback. Consider what they say through the perspective of your customer and adopt only what makes sense in that context.

Open up the floor to discuss how things are going. Specifically, pose these questions:

   What are the overall impressions of the stakeholders? What are they positive about? What concerns do they have?

   Are we on the right track with the scope of the product and progress to date?

   What additional business context and priorities come to mind relevant to the initiative?

   Does the team have any “asks” of stakeholders? (This may include support, resources, or information.)

   What are your next steps? (Make commitments to follow-ups.)

Follow up by sending a short note to everyone who attended the demo. Summarize what you heard and surface any significant issues that were not shared. It is common in a large meeting, particularly when all levels of seniority are present, that not all concerns are raised.

•   Conduct your own QA—Even if you have quality assurance team members supporting you, do not completely rely on them. Typically, QA is looking for technical issues and confirming that the product is working according to the specifications written. Two common issues tend to go unresolved unless you do your own QA:

1.  Interaction and visual design polish—If your product has a user-facing interface, it is possible that the intricate UI/UX and visual tweaks that make it intuitive and delightful were overlooked. This is not to say engineers don’t care about these tweaks, but polish is often very hard to specify and communicate in designs. It is also challenging to know what will work for the user until you try it out.

2.  Hidden requirements—Even the best product managers won’t catch everything the first time. You may realize you’re missing edge cases. It is common to find, after using your product, that features don’t make as much sense as you’d thought or work quite the way you imagined in your head.

Recruit your designer and some engineers to help you conduct this review. And your demo is a strong candidate for some more robust usability testing with prospective customers.

Now, though, is not the time to change user stories already completed—these are new requirements for future iterations and new estimates.

4. Retrospective or Post-Mortem

An often overlooked tool is the retrospective. It enables the opportunity to inspect, learn, and adapt your processes and ways of working. There is always room for improvement. The retrospective provides a safe space for the team to share recent experience while it is still fresh in their minds.

The goal is to identify actionable and constructive improvements. Generally, you wish to uncover:

•   what went right and what went wrong,

•   the issues’ underlying causes, and

•   ways to avoid similar situations in the future.

Structure your retrospective carefully. Participants should avoid getting personal and stick to the facts. Sometimes teams get out of the office and go somewhere fun, to warm up and break down communication barriers.

You can start a retrospective by revisiting outcomes from the previous retrospective. What changes did you make, what worked, and what didn’t? If the team did much better and the improvement became a new good habit, then celebrate. If it didn’t, discuss why and resolve to tackle it again. (Chances are, if it was the highest-priority opportunity for process improvement last time, it probably still is.)

Then discuss what went well and what didn’t go well in the cycle just completed. Remarks should be captured on a whiteboard or in a shared document. Themes tend to come up again later.

Here are two popular approaches:

(If you prefer, you can add a third category, “start,” to create a “start-stop-continue” list.)

A simple four-step structure will ensure maximum and equal participation from all involved. Use post-its and a whiteboard, or an online document you can all share and simultaneously edit.

1.  Individual brainstorm—Write down as many thoughts as you can. Try to make equal quantities in the different categories (don’t make them all bad thoughts, for example).

2.  Roundtable—Take turns to elaborate briefly on one to three ideas (doing three at once speeds up the process).

3.  Group similar ideas—Find any themes or related issues that emerged.

4.  Vote and commit—Decide on a few areas (no more than three) to improve, and commit to change.

Unless the team is very high-functioning, addressing just a few actionable and high-impact issues each time is all that is required. Communication and awareness improve merely by sharing feedback on other issues. One or two committed next steps provide the team focus and something they can all agree on fixing. Elect an owner to drive improvements, adding them into subsequent initiatives until the new habits are adopted or no longer relevant.