At Method, it’s our job to stay abreast of the best ways to create digital products. Through experience and research, we meet clients where they are and lead them in a better way to develop products. We call this perspective “Modern Product,” and it centers on how productive, successful tech-enabled product companies work.
In fact, we have an internal Modern Product Guild with the following mission statement:
“The very best tech-powered companies organize and manage their organizations, teams, and product work drastically different than most. So let’s understand the differences between how the best companies operate vs. most companies. And let’s align our ‘Methods’ to how the best companies operate.”
Our thoughts and perspectives about Modern Product stem from many sources, including Marty Cagan, Jeff Patton, and Teresa Torres. (If you’re working in an environment that struggles to create digital products well, Cagan’s video ‘The Root Cause of Product Failure’ will have you screaming “AMEN!”).
Much of what these creators discuss is making product teams empowered and autonomous. These teams are the atomic unit of Modern Product, and our principles all start with them in mind. These teams showcase attributes that enable them to own their decisions and outcomes. But more importantly, it provides the best opportunity to remain close to your users as they collaborate across the entire product development lifecycle. Companies that focus on nurturing environments where these principles can take root and grow will find themselves creating valuable, usable products that they can support with engaged and thriving teams.
8 Principles of Modern Product
How can you replicate this success in your own organization?
1. Durable, Cross-functional Product Teams
For a team to be autonomous, it must have the capabilities, knowledge, and authority to make decisions for the product. The knowledge feeding these decisions is only available if the team understands the business and includes members from all parts of the product development lifecycle.
Understanding a business domain and set of users takes time, so team members must stay with the team long enough to build that knowledge. In other words, the team is durable. “Durable” means the team focuses on their sphere of influence within the product or target market with largely the same set of members. At a minimum, this period is 1-2 years to benefit from shared experiences and internalized learnings and with team sizes of 7 (+/-) 2 based on cognitive capacity and Conway’s law.
If your product is larger, work to break it up across logical fracture planes that can be handled by a team of this size rather than a single, large monolithic team.
Digital Product Development consists of various stages that repeat as long as the product exists. First, there are discovery needs, like uncovering unmet needs and testing if the users find the product valuable. Then, there are build and operational needs focused on delivering the product to the users and measuring whether our solution is reaching the desired outcomes.
Each stage requires different personnel to evaluate and understand if what they are building is Valuable, Usable, Feasible, and Viable. Therefore, the team is cross-functional, meaning it has a team member to perform any task required to discover and deliver the product.
A famous “law” of software development is Conway’s Law, which states that:
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
In many enterprises, multiple teams are separated by disciplines involved in the development of product experiences. These teams either hand work off to each other or end up working on the same parts of the product at the same time with no well-defined interaction. The result is “spaghetti architecture” that is hard to deploy, with long delays from handoffs to teams that are already overburdened. There are no attempts to reduce cognitive load for the individual teams, so they have to keep the entire product in their brains all the time.
With Conway’s Law in mind, create small, independent and loosely coupled product development teams that have clearly defined interaction patterns. In Team Topologies, this is called the “Reverse Conway Maneuver.” There are minimal to no handoffs across the product development process or between the disciplines of Product, Design, and Engineering. Teams can move fast because they aren’t waiting on anyone.
2. Teams Handle End-to-end Discovery, Delivery, & Maintenance
Spotify sits on top of the podium as the gold standard of software organizations. The mantra “Think it, Build it, Ship it, Tweak it” comes from their organizational design.
This mantra means that the durable, cross-functional team creating the vision-aligned software is responsible for it from end to end. End to end means idea conception, validation, user testing, prototyping, design, programming, testing, deployment, bug fixes, and operations. Now, they can work to optimize the whole value chain, respond to feedback, and move at a quick pace.
One of the outcomes of this approach is that all members of the team are focused on the same goal: creating a valuable product. The programmers aren’t focused on just feature creation, the ops people aren’t focused on just system uptime and performance, and the product folks aren’t just focused on user experience. The whole team works toward metrics that are good for the product and its users, not for their individual disciplines.
Technology choices become important using this model, because the team needs to generate feedback quickly so they need to have a replicable, easy-deployment process. Onerous environment creation or time-killing compliance processes hurt the effectiveness of the team and the value they create. Since they control the entire lifecycle, the team can focus together to create the best process and technology choices to achieve their goals.
Spotify Example: Cross-functional teams responsible for the end-to-end Discovery and Delivery within a bounded part of a product or product experience across natural fracture planes.
3. Applied Principles of Design Thinking, Lean Product Development & Agile
Product Development comes with a large toolbox. Where you are in the life of a product drives what tool comes out of the box. Good product teams manage risk early, using design thinking to really understand the problem, involve users early, and brainstorm many solutions.
Next, the team prototypes those solutions using Lean Product Development to learn what works and validate ideas quickly and efficiently. Now, with validated product ideas, Agile Software Development creates robust software in a repeatable manner. Releasable software is created in short, time-boxed iterations to maximize feedback and show progress.
While many companies apply Agile principles to building software, the unfortunate reality is the vast majority use a sequential and siloed (waterfall) approach to the end-to-end product development process where product, design, and engineering are separate phases that are stitched together with documentation and handoffs. Effective teams utilize these principles throughout the entire lifecycle in order to create solid outcomes.
Use the right tool for the right job.
4. Alignment on Product Vision and Product Strategy
Most people agree that alignment on a vision is a solid practice for any endeavor requiring a team. But this becomes essential if you hope to provide your teams the autonomy to discover and deliver on outcomes. The team must understand the Product Vision, which articulates “Where are we going?” within the next 3-5 years.
Without this understanding, team focus is aimless and devolves to cranking out features without considering how those features fit in with the vision. There are a myriad of tools to externalize and align on Vision across the organization and teams, including vision prototypes, product narratives, and storyboards. This is one of the most important and overlooked steps when developing digital products.
If Product Vision answers the question “Where are we going?” Product Strategy details “How will we get there?” Building this strategy entails answering questions like:
- What customer segments will we focus on and in what order?
- What customer needs, wants, and pain points should we focus on solving?
- How are we differentiated within the competitive landscape?
- What architecture and tech stack will support repeatable deployments?
- How are teams structured across the product and/or product experience?
Aligning on the answers to these questions and, thus, the Product Strategy gives the team the knowledge and tools it needs to make informed decisions to reach desired outcomes.
Your Strategy is equally about what you’ll focus on and why, as it is what you won’t focus on. Strong organizations are 100% aligned on these topics from the C-suite down to each contributing Product Team.
5. Empowerment to Collaboratively Explore the Problem and Solution Space
Modern Product teams are not Feature Factories, nor are they order takers. Instead, today’s successful product development teams receive objectives, measures of success, and guardrails. From there, it is up to the team to figure out how to hit the goals of the product. Leadership does not micromanage; instead, they work with the team to set time-boxed outcomes, checking in frequently on progress toward those outcomes. This is a top-down meets bottom-up approach that ensures the proper context for the teams while giving them the autonomy to own their outcomes.
6. Continuous and Direct Customer Input for Experimentation and Validated Learning
There is an adage that claims users don’t know what they want until they see it. The right product lives in the minds of users and is emergent. Effective teams perform activities to pull the product out of the users’ minds. If there’s one concept to keep at the heart of your product development process, it’s “Minimize the gap between Maker and User”.
We use continuous discovery work to gain a deep understanding and empathy for the questions of: Who are your users? What are their needs, wants, and pain points? And do they find our ideas valuable and usable?
Marty Cagan (in the aforementioned and linked video) cites two contributing factors to failing software around this concept:
- Teams get their product ideas from the wrong places.
- Customers are brought in to the process way too late and not often enough.
In both cases, the risk of creating the wrong product is almost guaranteed. Modern Product teams tackle the value and usability risks early by involving the customer on day one and continually from there. Talk to actual users or customers to understand their needs, desires, and pain points. Design prototypes, which are cheap to create and can get concepts in front of customers, early and often. Get user feedback continuously, and incorporate it before any expensive delivery takes place. This type of generative and evaluative user feedback and product refinement happens very frequently – ideally, weekly – and collectively by the team making the product.
Lastly, it’s important that all team members (Product/Design/Engineering) are involved in discovery work. No amount of documentation can provide the insights experienced and internalized through direct customer input. Kill handoffs.
7. Measured on Outcomes, Not Output
(Given problems to solve, not features to build.)
The difference between outcomes and output is key to successful product development. Outcomes are positive changes that the team brings into existence. Outputs are simple indications that work happened. Outcomes measure new customer value; outputs measure new features. Here are a few more examples of outputs vs. outcomes:
| Outcome | Output |
| More customers onboarded | New onboarding pages created |
| Deployment frequency increased 20% | Team Velocity |
| Downtime reduced by 10% | 10% more bugs fixed |
| Customers reduced their debt by 10% | Launched debt calculator |
Outcomes drive towards a more valuable product, while outputs drive toward more activity. Modern Product teams measure themselves by achieving the aligned desired outcome, not with activity metrics like velocity or features created. Because of this, Modern Product organizations align and plan their future goals through outcome-driven roadmaps or techniques like OKRs, not via prioritized feature roadmaps.
8. Team Health Above All Else
Team Health is represented across six key dimensions: Autonomy, Mastery, Purpose, Community, Security, and Wellbeing.
The first three will be familiar from Daniel Pink’s Drive, The Surprising Research About What Motivates Us. In his research, Pink details how they lead to better performance and personal satisfaction.
Autonomy is our desire to be self-directed and to chart our own path towards successful outcomes. Provide autonomy through loosely coupled cross-functional teams that have end-to-end responsibility for Discovery, Delivery and Maintenance for their sphere of influence within the Product.
Mastery is one’s desire to grow and improve themselves over time. Building impactful digital products takes all sorts of creative and technical skills that are ever-evolving. Embed opportunities for personal and professional growth and time to realize them. Celebrate team members learning new skills and experimenting on ways to improve your teams, product, and process.
Purpose is our intrinsic desire to be a part of something larger than ourselves. Deep purpose should be present across all hierarchies of the organization including Company, Product, and Team. The very best teams are powerfully motivated to serve and contribute to a better tomorrow.
The last three dimensions of Community, Security, and Wellbeing are key indicators for high-performing teams collaborating in an environment of ambiguity, experimentation, and shared learning.
Community is about creating a supportive network where the whole is greater than the sum of its parts. Product development is a team sport. As Marty Cagan says, create structures that support Missionaries, not Mercenaries.
Security focuses on creating a culture that understands that failure is needed for innovation and growth. Provide teams with the psychological safety needed for rapid experimentation and yes, failure.
Lastly, Wellbeing focuses on supporting your teammates’ holistic self beyond work through work-life balance, physical, mental and emotional health. Just like all interpersonal relationships, team health is dynamic and takes continual investment and energy to maintain.
Creating team structures and product development processes that enable and support autonomy, mastery, purpose, community, security, and wellbeing is the lifeblood of Modern Product and healthy teams.
Conclusion
The reality is that customers want value now. If they can’t have it now, they’ll take it ASAP. The pressures on a Product team, especially in crowded and competitive industries, feel heavy and constant. Business and leadership often want predictability, pushing the product people into supplying estimates, which are surely wrong. So on top of the pressure to meet the market, there is pressure to meet the forecast.
Here beginneth the death march.
Product Development is a Complex Adaptive System. There is no telling how long it will take to build the next best product, but it will take time and iterations. Products are never done, so making minor improvements over time is how the proper evolution emerges.
Give your team time to decompress, learn, and celebrate, and they’ll come to work refreshed and full of ideas and ambition. A healthy team is a happy team, and that happiness will convert into a quality product.
Our team at Method is constantly considering and discussing ways to improve product development. Not only do we want to create better products faster and more durable, motivated, engaged teams, but we sincerely want to teach our clients better capabilities. This list of principles represents our current mindset, but we expect it to continue to change as we learn, technology advances, and our industry evolves.
How do your product development teams apply these principles? If you’d like help improving product development or starting on the right path, come talk to us.
Additional Good Reads:
Inspired & Empowered – Marty Cagan
Continuous Discovery Habits – Teresa Torres
Outcomes Over Output – Joshua Seiden
The Lean Product Playbook – Dan Olsen
Team Topologies – Matthew Skelton, Manuel Pais
Accelerate – Nicole Forsgren PhD, Jez Humble, Gene Kim
Measure What Matters – John Doerr
Lean vs Agile vs Design Thinking – Jeff Gothelf
Product Roadmaps Relaunched – C. Todd Lombardo, Bruce McCarthy
User Story Mapping – Jeff Patton