In a nutshell a Product Team is comprised of a design, product manager, and engineer. Each product has its own product team. (Ideally, given the commitment, individuals are never members of more than one team.) Building on the core concepts of Agile, another way to look at this model is a tripod with its three legs collectively supporting the product, and elevating it to it full potential. (Trio is also a common term used for this model.) In Scrum terms, the Product Team is the Product Owner.

Of course QA, Documentation, and Customer Support need to be there as well. It is the responsibility of the Product Team to ensure these teams are included in the planning and throughout of the project as needed.

The Product Team is not meant to exclude, its meant to identify the people who are accountable for the product and for ensuring QA, Docs, Support, etc., are also in the loop--as well as Sales, Product Marketing, PS, CSM, etc.

A secondary goal of this model is to reduce the number of meetings everyone has to attend, especially early in the product lifecycle.

Product Team model for development

Product Teams are responsible for the outcomes of their product development team, the health of that team, the roadmap of that team, the vision, and the customer satisfaction, all of it. Collectively the Product Team will work to ensure the problem opportunity does indeed address real customer needs, and provides the company with a compelling way to increase revenue and gain market share, while also enabling customers to be more successful and delighted with our products.

The day to day deliverables are captured in the Product Development Pipeline. What follows is a description and best practices for operating this model.

Traditional Development Model

Historically, product management has been tasked with building products that are valuable to the business, as well as customers. Design has been tasked with building something that is usable and desirable, providing a great user experience that is intuitive and easy to learn. And Engineering has been tasked with building products that are practical, scalable, and stable with fast performance and zero downtime.

The development model ran something like this:

Once upon a time… a PM developed a roadmap and once it was done she sat down with the Designer and told him what the product needed to do and how it should work. The Designer was filled with questions, so he started asking the PM who? why? how? (Why actually came-up again and again…) But after a couple weeks the designer finally had a set of wireframes he and the PM could agree on.

Setting off together the PM and designer go to find the Engineers. The Engineers were surprised to learn a new product was in the works--but not surprised it had been fully spec’ed out. Looking over the wireframes, the engineers scratched their heads, and got out their red pens… They were trying to figure out how to build such a thing, let alone in the timeframe the product manager requested.

While they all negotiated trade-offs and debated features, the designs were being updated on the fly and tech debt was being accrued. The product marketers where pounding on the door, the documentation team was writing and rewriting their notes. Meanwhile outside in the dark woods, the deadline was creeping closer and closers.

In the end no one lived happily ever after.

This classic hand-off approach leads to miscommunication, unnecessary iterations and delays, assumptions, frustration, introducing four types of risk:

• Value Risk: will the product provide enough value for customers to want to buy it?

• Usability Risk: will the product still be usable and easy to learn?

• Feasibility Risk: can it be built in the given timeframe? How much tech debt will be created?

• Viability Risk: will the final product fulfill its role in the company’s strategy?

  For additional information on Product Team and the Product Operating Model, ready “Transformed” by Marty Cagan and the Silicon Valley Product Group

The Product Team Model

The team helps to ensure engineering, design and PM are aligned from the beginning of a project--before there is roadmap or a 6 Pager. This is to minimize time spent in hand-offs, getting new people up to speed, and avoiding misunderstandings and assumptions. All of which can collectively delay the project and have a negative impact on the collective morale of the organization.

As with all teams, the Product Teams will likely go through the Forming, Storming, Norming, and Performing phases. But over time this method will become second nature, and new Product Team will hit the ground running.

The Product Team is responsible for:

The 6 Pager
While one member may take point on drafting the 6 Pager, all three members need to contribute to the document. By adding their perspectives the team will ensure the document checks all three boxes of product success: desirability, feasibility, and viability.

Discovery, Definition, Ideation, Prototyping, Testing…

When the project is kicked off it will go into the Discovery Phase, where all three members of the Product Team will actively participate in the customer interviews, co-innovation workshops, etc. Likewise they are all expected participate in the full process from Definition through testing.

Definition of Ready
The Product Team is responsible for defining when they are ready to move into development. Again the team should also collaborate with Product Marketing, Support and Documentation to ensure the full organization is prepared.

Development
At this point the Product team will gain additional resources to help with the actual design and development of the product. But this team will still be responsible for prioritizing and directing the work.

Release Planning
Here again rather than this being the sole responsibility of the Product Manager all three members of the Product Team are responsible for defining the roadmap and presenting it in the Release Planning meetings. The team should also work with Product Marketing, Support, Documentation, Professional Services, and Customer Success.

Scrums
In the Scrum of Scrum meeting the Product Team will be prepared to provide updates to the larger group regarding their progress, risks and assessments

Execution Plan Reviews
Providing the leadership with regular updates on their progress, all three members of the Product Team--as well as other relevant members of the larger team, will help prepare for these reviews (i.e. product marketing, documentation, support, etc.)

Training
The Product Team should coordinate with our training team to create any content needed for the release. Ideally the training content should be completed by the release date.

Definition of Done
The Product Team will collectively define the acceptance criteria for their product

Community
Community provides a place for product initiatives to be promoted and supported. The Product Team will be responsible for working with the community to create spaces for their products and work with Product Marketing, SEs, and others to create supporting content.

How to engage with a Product Team

The team will be the primary face of the product inside the organization. So when other teams from SnapLogic need information or support from the product, they should reach out to the Product Team for assistance.

Sales, SE’s, Enterprise Architecture can engage directly with the Product Team to provide customers with roadmap updates, and to set-up Co-Innovation workshops with customers

Product Marketing should reach out to a Product Team to set-up conversations about release dates, promotional and launch prep, go-to-market planning, and any special events.

Community should work with the Product Team to create events and content to help support and promote the product initiative.

Support should share problems and recurring issues with the Product Team

Program Management will need to coordinate with the Product Team for release planning and tracking their progress

Additional Tips

In addition to the team’s deliverables, there are some additional best practices for a successful Product Team:

• Shared ownership leads to shared understanding. This model expands everyone’s focus, while collectively ensuring everyone is working toward the same goal, reducing risk and accelerating delivery.

• Understand the needs of each stakeholder. Have a deep understanding of the needs of your customers, executives, and the company’s strategic vision.

• Product development is a team sport. Creating products truly is a sport, and while each team has specialized positions they are all focused on the same goal.

• Handoffs are deadly. Miscommunication issues can occur when specifications get handed to different teams, additionally each handoff is followed by a ramp-up, delaying delivery. Try to avoid them, especially late in the game.

• Set clear priorities. Prioritize features based their importance to customers and the company’s strategic plan, while balancing tech debt with emerging trends.

• Be flexible. As the product develops from idea to tangible solution, there will be constant changes, learn to adapt and to communicate the changing needs to the larger organization

• Be data-driven. Informed choices help ensure alignment and long-term success. Collect data on customer behaviors, needs, pain points; market trends, competitive threats, and emerging technologies.

• Be collaborative. Avoid the divide and conquer mindset, work together: the goal is to be a single team and with different perspectives.

• Three person teams have tie-breakers. With three votes there is never a tie, each member has equal say; no one person runs the show and no one person shoulders the risk.

Longterm Benefits

The side benefit of this approach is that you build product minded leaders. Ultimately whether it's an engineer, PM, or designer, as these Product Team progress in their career this experience will help shape them in to strong product leaders who are committed to building great solutions. They will also develop a strong appreciation for other disciplines, understanding how each approaches problem solving, their tools, methodologies and processes for exploring and resolving problems. Membership in Product Team a will also develop effective skills for collaboration and communication, and more importantly how to actively listen to others.