Product Development Philosophy
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 feedbackCompany 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:
What do we do with all the feedback?
How does this process scale over time?
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.
- 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:
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 membersHead 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.
Product manager & Engineering lead for each dev team
Subject matter experts to comprise each dev team, as necessary depending on each team’s objectives: Developers, designers, QA, data specialists, DevOps, etc
Liaisons or contributors from other divisions that take part in product development as required:
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 successI 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.