I have learned that there is no one-size fits all model for building and maintaining a high performance product development organization. However, my experience has taught me that there are consistent general principles that dictate the success of the product. 

• Whole organization must be “agile”
• Objective-specific, interdisciplinary dev teams; strong interdependence within teams
• Teams must be empowered to do their jobs; minimal interdependence between teams
• Effective lines of communication between developers, customer success, marketing, sales
• Carefully balance power and communication dynamics
• Don’t be afraid to have “too many” PMs
• Each product manager needs an engineering counterpart
• Autonomy requires alignment

The whole organization must be agile

• Good product development practice involves everyone in the company, not just product managers and engineers. Most important: company leadership embraces Agile principles.
• Company priorities should be managed in a collaborative, living document. I like to use a Kanban board. This enables clear negotiation of relative priority and enforcement of a works-in-progress limit for the leadership team.
• The board includes all company priorities—not just product development.
• There is an expectation that new objectives will be considered only via data-driven, rigorous proposals. I favor the Amazon “working backwards” approach. Team members read each proposal before commencing discussion. 
• Test ideas via data analysis and/or experiments. Nothing advances past the proposal stage based on a hunch.
• Focus on problems to solve—solutions should be explored only after including subject matter experts. Company leaders in many firms spend lots of time spitballing half-baked solutions and involve experts way too late.

Reference: generate and act upon market feedback Company objectives and priorities should be determined via a rigorous process, but it’s important to balance anecdote-based intelligence with “hard data.” It’s conventional wisdom that a data-based approach is always better. Nevertheless, it is my experience that we have to be wary of the results of our data analysis. Gaps in our dataset, methodology flaws, and wishful thinking can result in false precision. Arguably, anecdotes can be very useful. There’s no substitute for the individualized insight that a few in-depth conversations with real users can produce; nevertheless, putting too much stock in what a subset of users think they want can also lead us astray.  Some insight-collection methods I’d recommend: Use a tool like Fullstory to monitor user activity to try to identify areas where users are getting lost or their expectations are being thwarted. Track errors and failures, then investigate their source. Implement context-sensitive help in the user interface, not only to help users resolve their issues, but also to be able to measure which parts of the workflow are most confusing. Then include the ability for users to leave context-sensitive feedback and interact with support staff in real time. Perform demand experiments in the UI: tease proposed new features to measure enthusiasm and solicit feedback. Perform demand experiments via marketing: tease proposed new features in newsletters, via online ads, and other media, resolving to landing pages that allow people to enroll in focus groups, sign up for future beta tests, and provide immediate feedback on the concept. Regularly build rough prototypes and put them in front of your best customers to prompt them for feedback; ask open-ended questions to foster blue-sky thinking on other topics while you have their attention. Channel company staff’s experience into productive feedback (see “Communication between business units” below.) Consider publishing a curated public roadmap and accept feature requests from users. Pay close attention to competitors’ releases and to public forums where users air likes and dislikes, and do the same for non-competitors with similar products or workflows. What do we do with all the feedback? Everything should be recorded in a shared interactive repository such as a Trello or Airtable board, then tagged and organized: appended to an existing entry, or added as a new one. Product team should review incoming feedback regularly. Some feedback relates directly to already-existing company objectives (active or proposed). Any insights from that feedback should be added to its entry in the company’s central strategy document in order to bolster the case. PMs should coordinate with that initiative’s champion in the org. Some feedback may make the case for a major new company initiative. The PM that makes this connection should share it with stakeholders in the org to see if anyone would like to champion it and use it as the basis for further validation/experimentation in order to eventually become part of a proposal to be shared in a strategy discussion. Some feedback may provide insight on fixes or improvements to existing features. It should be discussed during routine product planning. Often, the insight will prompt additional research, validation, or design work rather than going straight into the development roadmap. Feedback that is valid but incompatible with current company objectives should be filed away, unless it’s so compelling that someone feels that company strategy should be modified, in which case there should be a forum for them to make that case. How does this process scale over time? At first, PMs work with engineering or data science staff on an occasional basis to deploy monitoring tools and dig into data. As the headcount grows, we can deploy a full time data insights team within the product org. A lot of insight gathering that initially depends on manual parsing and organization can be automated over time, leaving only high-level analysis to human beings. All product managers should be collaborating with designers and engineers on their teams to design experiments, mockups, and MVPs to test ideas. As the organization grows, it may make sense to have a dedicated team to support those efforts. Eventually, working with stakeholders across the organization and organizing their contribution to product development will need to be one product manager’s full time job, rather than being spread out across all PMs. Supporting new functionality that is related to new partnerships will initially be spread out among the dev teams as appropriate. At some point that workload may expand to the point that an entire dev team may need to be dedicated to those activities.

Interdisciplinary dev teams

• Potential dev team members may include: product managers, developers with various specialties, DevOps, designers with various specialties, data scientists and data engineers, product marketing specialists, customer success managers and onboarding specialists, finance and risk specialists, and others, depending on the team’s objective.
• Dev teams will be reconstituted periodically based on tasks to be done, and experts will migrate to teams where their expertise is needed. This also supports good morale as developers get the chance to “mix it up” and learn new things.
• Some team members may work in departments, such as customer success, marketing, business development, operations, or finance that don’t typically have a formal role in product development. They can float in and out as necessary.
• PMs become subject matter experts in their domain, and preside over teams to work on problems in their area. The PM’s authority is strictly servant-leadership.
• Interdependence within the team: tasks will generally require several team members to collaborate closely. Try to prevent anyone from having to work alone for too long.

Empowerment

• Company has a clear, concise product vision that is written down in a prominent place, and company leaders refer to it often. Every team member can be secure in the fact that there is consensus around this vision. (Making sure this remains true is the head-of-product’s primary responsibility).
• Each problem-to-solve is clearly defined and backed with data.
• Teams are staffed with the most effective people to be able to complete their tasks. Move people between teams when necessary. Any team contributor can marshal necessary resources with limited pushback. This may include deputizing a posse of experts from outside the product development organization.
• The dynamic within each dev team is egalitarian. The PM is not “the boss” of the team. There’s an environment of mutual respect and each member is valued for their specialized skills and contribution.

Communication between business units

• Sales and support staff are invaluable to product development because of their proximity to end users. Channel the relationship with those teams into productive feedback.
• Involve developers in strategic planning early. They should be a part of problem solving.
• Schedule regular events where dev teams demonstrate new features and capabilities to company stakeholders and make themselves available for feedback. “Dog and pony show” meets listening tour.

Balance power and communication dynamics

• Don’t allow company leadership to short circuit the process and sidetrack or intimidate developers.
• Don’t allow contributors with big titles or strong personalities to skip skips or “shoot from the hip.” Enforce process rigor. See The Dangerous Animals of Product Development.
• Try to prevent dev teams from being overwhelmed with reactive, raw customer feedback, or get bogged down in endless cycles of tech support.
• Don’t allow the extroverts to do all the talking. Balance in-person meetings with in-writing inputs, and coax out contributions from quieter team members. I like to encourage asynchronous, written communication as much as possible, because in-person meetings are tiresome and expensive.

Case study: prioritizationIn an earlier section, I described using a Kanban board to keep track of the company’s or the dev team’s strategic objectives. It would look something like this: Within each column, we sort the initiatives into priority order. If there isn’t broad agreement among stakeholders about priority, we can use a variety of prioritization exercises to balance costs and benefits, but in my opinion, unresolvable differences of opinion about what the priority should be is an uncommon problem. More common is company leaders either being unaware of the priority, disregarding it, or trying to bypass the process. The most important aspects of this approach are: Each of these columns has a works-in-progress limit. In this case, no more than five initiatives are permitted in the implementation phase, and no more than ten in the backlog. Anything that doesn’t fit needs to be demoted to an idea. We can experiment with different WIP limits until we figure out what’s right for the org. There will absolutely be new and exciting objectives that come to light and are proposed to be added right away to the implementation phase or put at the top of the backlog. In order to maintain order and enforce rigor, this kind of modification to the strategy involves moving the new initiative onto the board and displacing something that’s already on the list. It’s very helpful for everyone to be able to actually visualize this new thing pushing some other objective off the list. You need to kind of blow a trumpet when it happens, because otherwise someone will always ask “what happened to X? Aren’t we doing that anymore?” Sometimes there has to be a big fight about what gets pushed off. That’s okay. An idea may be placed in the backlog only after it has reached a baseline level of development: Data has been gathered and organized, demand tests performed, feedback organized, industry trends analyzed, etc. I like the culmination of this work to be a proposal that company leaders read and discuss. This document includes a first stab at OKRs. During the discussion, company leaders refine the OKRs and the initiative is either promoted to the backlog or sent back to the research or idea columns, or deleted. Champions for the idea will have their picture attached to the card on the board, and that idea will be placed in the research column while that work is in progress. Champions should only be working on one project at a time, ideally, so I like to loosely enforce a WIP limit for that column too. Once something from the implementation column is shipped, then something from the backlog, most likely the top item, can take its place. Items aren’t moved around on this board without input from a quorum of company leaders, however. We need to get the metaphorical trumpet out for these events too. Within each card, we’ll compile the OKRs, a brief summary of dependencies, proposed phases, and notes, and links out to any other systems that the team uses for project management. In the below example, each objective corresponds with a Jira epic:

Product Management staffing

• There are industry rules of thumb and prejudices around “there should be X PMs for every Y engineers.” I don’t subscribe to these notions. The right engineer-to-PM ratio is entirely dependent on the nature of the work and the skills of your individuals.
• Your main concern should always be whether everyone is able to maintain maximum productivity. Try to prevent people working on tasks that don’t suit their skills or working on projects that leave them feeling unfulfilled for long periods of time. PMs and the head of product should confer regularly to assess their teams’ productivity wellbeing.
• Product Manager does not have to be a static role in the organization. Depending on their skills and background, PMs may serve a stint on a dev team that’s headed by another PM in a design, engineering, or data specialist capacity. I have a lot of experience mentoring designers or engineers that are interested in product management, and giving them an opportunity to learn and explore, and eventually preside on a dev team. While I’m leading the product organization, I might also contribute as a designer, developer, researcher, or analyst on a dev team from time to time, as appropriate, to stay sharp and grounded.

Each product manager needs an engineering counterpart

• Nominate an experienced developer to be the “right hand” of the PM on each dev team.
• The PM focuses on prioritization. The engineering lead negotiates speed/quality tradeoffs. They collaborate on discovery and validation.
• A team’s engineering lead does not need to manage the team’s engineers in the org chart, but does need to be trusted and respected.

Reference: key team members Head of product & head of engineering Just as each PM has an engineering counterpart/partner, the product leader and engineering leader should have a close working relationship built on trust and mutual respect. Together, they’re responsible for devising and executing solutions for the objectives laid out by company leadership.  Company leadership: The head of product is responsible for fostering collaboration and consensus among the company’s strategic leaders and being a facilitator for strategic communication between the product development team and other divisions.Product manager & Engineering lead for each dev team: Heads of product and engineering should provide mentorship and guidance, clearing the way so each PM and engineering lead can operate at maximum impactSubject matter experts to comprise each dev team, as necessary depending on each team’s objectives: Developers, designers, QA, data specialists, DevOps, etcLiaisons or contributors from other divisions that take part in product development as required: Sales engineers, product marketing, customer success reps, business development, finance

Autonomy requires alignment

• It’s impossible to have a high-performance dev team without autonomy. Nobody should ever wait around for instructions or to receive the resources they need.
• Autonomy without alignment leads to chaos and wasted resources.
• Company leadership needs to be disciplined about product vision and do the hard work required to achieve alignment around strategic objectives and prioritization.
• Begin with the end in mind: make sure you’re aligned on desired outcomes and how to measure success
• Properly communicating vision, objectives, and priorities is difficult and time-consuming. It requires constant tending, like a delicate orchid. It’s not set-it-and-forget it. To maintain a high performance organization, it should be expected that this responsibility monopolizes the head-of-product’s time.
• Some communications burden can be alleviated with high levels of trust, so expend continuous effort to build and maintain that trust.

Reference: how to define success I like to do an OKR exercise for each major company objective, then another one for each product objective that the team devises as it deconstructs the company objective into components or phases. One of the benefits of this approach is that we begin, early in the process, to define what a successful outcome will look like.  One of the core principles of the Agile Manifesto is “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” I believe that this principle harmonizes very well with the OKR framework in that, as part of a regular retrospective, the teams can reexamine each project’s stated OKRs, consider its progress toward achieving the key result, and make whatever modifications are necessary to achieve the desired outcome. Sometimes, the team will realize that some or all of what’s in the OKR is flawed, and they have an honest discussion about its modification, guided by the company’s product vision and consulting with stakeholders. A high performance team embraces the fact that all projects start with limited understanding, and specifications will change as the project progresses. One of the product leader’s most important responsibilities is to ensure that the company’s product vision is clearly articulated and realistic, and to help guide dev teams through the process of confronting the ever-shifting discovery landscape as they devise and execute solutions.Ultimately, the primary way that a product organization succeeds is that it produces and deploys software that meets customer needs and advances the company’s strategic objectives. As the late, great product manager Steve Jobs said, “real artists ship.” You can have the most intricately designed and rigorously followed process, and a high-morale team made up of the most skilled professionals in the industry, but it counts for nothing if you can’t ship lots of good code.