??How Real Is Your Team? Marty Cagan vs. Feature Teams ?? #prodmgmt

Marty Cagan is one of the biggest names in product management and is a prolific thinker & writer. Some consider his book "Inspired" to be the Bible for Product Managers.

This episode on the DesignBetter show surprisingly doesn't rehash a lot of his past work. In it, Marty goes deep on some of the ideas around prototypes, real product teams and how to drive value.

I spent 2 years working with software teams, and it was a mess. While I knew the theory and had this nagging feeling that we were doing it wrong, I had no one to turn to for advice.

Below are my notes from this podcast, interspersed with connected ideas and original insights & examples.

One complements the other, so you can use both. (And talk to me if you'd like more advice. I can tell you what NOT to do! ??)

SO!

How does your team stack up against the definition of a real product team, according to Marty?

Do you know why use prototypes? What 4 types are there?

What risks should you always think about in your product?

Read on for this and much more.

Do We Agree On What's a Product? And Who's In a Team?

Who’s In a Team?

A product team has a Product Manager, a Designer and a Tech lead + 1-2 engineers. It's great to have QA and an analyst too if you're lucky. 

Any other definition and I would consider them something else, not a (software) product team. I've seen teams that had 1 engineer + people from various non-technical functions. No designers. They may have adhered to Agile principles, but they weren't software product teams.

What’s a Product? (The Quick Version)

Together, a team works on something that exists or needs to exist (in which case, it's a problem not a product yet).

It would be out of scope to talk about what a product is at length. John Cutler once explained to me that a product was something that provided value (my interpretation, anyway).

In ecommerce, a product might be the algorithm that generates search results. Without it, customers would have no way of discovering your products. Its value is "better discovery". Your team optimises for it.

Or it might be the actual products you're selling. The team handles a lot more, branching out into manufacturing and/or marketing. The product won't win unless they optimise the ads and product pages for conversion.

Or it might be the payments system. Without it customers would not be able to pay, refund, use PayPal, etc. The business would not be able to connect with Xero, or their ERP, etc.

Companies like Xero or Spotify often advertise roles at a team level.

These are all products (unless someone from Xero or Spotify comes here and proves me wrong). Makes sense?

This is an idealised vision. Lots of companies don't do this delineation in responsibility. Such a decision leads to confusion about who's responsible for what. Not good for results.

The Definition Of Real

There are 2 kinds of teams, according to Marty.

1. Feature teams
2. Real product teams

Feature Teams

Feature teams get feature requests from stakeholders. The product manager is a product owner on a Scrum team. She grooms the backlog, prioritising according to the feedback from the stakeholders. She throws the specs over to the designer and/or engineers in one shape or form, even if they are co-located.

The designer designs according to those specs. Then she throws the Sketch/Figma files over to the engineers; the PM often adds their 2 cents to it.

The engineers build what the designer has designed and what the spec says.

They measure progress by shipping features.

Real Product Teams

Real Product teams get a product vision and objectives from the stakeholders. They think about the 4 types of risks in their work - feasibility, viability, value and usability. They make lots of prototypes to lower those risks. 

The PM, designer & tech lead solve the problem side-by-side.

The designer starts to make prototypes. The tech lead looks at them to see if she can solve it better and if there's something that freaks her out. If it does, the tech lead makes her own feasibility prototypes (more on them later).

The product manager looks at whether they can market and sell this nascent idea. They think if it complies with the rules and regulations of the industry or company.

In the beginning there are a lot of dead ends and scrapped ideas. The designer often discards the prototype when she sees that the idea might not work.

These teams measure progress by the degree of solving the problem.

How Do The Real Ones Work?

Dual-Track Agile

Teams are encouraged to embrace the dual-track agile approach. It's known by many names.

Concepts like the Double Diamond can wrap around this concept. You seek options, then refine them, then pick a path, then refine the path. 

It’s not an issue with feature teams because they’re just designing and building. It’s not that they don’t have time, it’s that no one asks them to do it.

But feature teams might think they're doing the Discovery/Delivery while literally doing Waterfall. Go back to the earlier definition.

When the PM > Designer > Eng flow happens and it happens one way, even if you do "discovery" a week before that happens...

Real product teams are figuring out a solution that works:

• Figuring out what to build before writing production code
• Most ideas don’t work
• They have to fake it before they make it, a lot.

Discovery in Dual-Track is not a phase. Engineers continue to build every week.

Continuous Discovery

Meanwhile, the team does continuous discovery, using various techniques.

One of them may be Design Sprints. Such heavy techniques are way overkill for most things in the product team's life. Marty advocates that Design Sprints should happen once a quarter at best. They are awesome for when there’s a hard problem to solve.

Whatever shape it takes, this is continuous discovery, also popularised by Teresa Torres. Teams have to use qualitative and quantitative methods, worked into habits. They have to be well-versed in these methods.

Athletes don't exercise once in a while or when their scale breaks. They exercise even if they're at the top of their game.

Spending at least 3 hours per week with customers is a must, 5-10 hours if you’re doing a big redesign. 

Qualitative: 

• Going to the customers
• Having interviews with them
• Doing remote sessions

Quantitative: 

• Running A/B tests
• Instrumenting events in analytics
• Designing metrics

Marty advocates against Focus Groups. Focus groups have a use, but there is a risk of groupthink and bias in them. These are the silent killers of any innovation.

Marty also suggests avoiding surveys unless you know what you’re doing. I agree:

Unless you have a UX researcher or a data scientist to help structure it, a survey may lead you astray.

4 Types of Prototypes

So, what do we know by now?

Teams have to be well-versed in many techniques for discovery. This is bread & butter for the consultants, but truly, if you're curious enough, you don't need consultants to create a Figma account and make a prototype. (You need them to refine your technique though, like a coach would do.)

Teams have prototypes as their main weapon in the war against risk. They pick prototypes that address the various 4 risks their product is exposed to (feasibility, viability, value and usability).

The broad types are:

1. User Prototypes/Simulations
2. Feasibility Prototypes
3. Live Data Prototypes
4. Custom Hybrid Prototypes

User Prototypes/Simulations

The most often used. The designer creates them in a few hours using tools like Sketch + Invision, Figma, Framer, etc. 

Feasibility Prototypes 

Less known, but powerful. The engineers create them in code when they are not sure about how to build something. Machine learning applications often fall into this group. Such prototypes are critical when needed. When a 2-week project takes 5 months, it’s likely the team plunged into it without a feasibility prototype.

Live Data Prototypes

Used when we need to collect data and we’re not sitting down with the user. The designer & engineer create these over a few days. This is moving into a more quantitative method space. We constrain this prototype to a limited number of users (100-1000 users). 

Custom Hybrid Prototypes 

The most creative types, and they take a lot of work. The team looks at the 4 risks and makes 1 prototype that addresses them all. Such prototypes have elements of user prototypes, live data prototypes, Wizard of Oz prototypes, etc.

Customers And What They Value

What Do Customers Value?

When it comes to the the customer, what you have to care are 2 things:

1. Is our product usable?
2. Is our product valuable?

Usability is fairly straightforward to test and there are good techniques to do that.

Ryan Singer (Basecamp) reckons usability testing is not that necessary:

But value... Value is very difficult to get a signal for.

It’s simpler if you’re thinking of selling an ebook, for example. You slap together a nice landing page, with a Buy Now button. There is no book yet and there might never be one, so people can’t actually buy it. 

If people click the Buy Now button, then you get a precise signal for how many people would buy it. Can you even prototype the full payment solution without connecting the backend (to avoid a charge going through)? You won't even have to adjust the number of clicks on Buy Now to weed out those who would drop out at entering their credit card details.

You can then figure out if you can scale this with ads or other means. In general, there should be fewer doubts whether someone wants what you’re about to make.

But most businesses are not freelancers selling e-books. The challenges of finding the value signal have been written about at length. We’ll forever be in search of better, leaner ways to tell. Yes, sometimes you have to take the leap - if it works for the business, if this risk is acceptable. 

But this leap is usually taken way sooner than is acceptable.

Product Value Confidence Tools

Itamar Gilad offers his own take on the confidence and when an idea is ripe. 

I created a translation of those terms for my own use:

The further on the wheel, the more ready we are to commit various resources to the product. And it’s not just about writing code. The whole org needs to come together to make it work, which is why stakeholders are super important. We'll need their resources too.

You get their buy in by getting their trust. You get their trust by shipping stuff that delivers value and delivers it on time.

The Stakeholders Are Not Customers

In feature teams, the business is asking them to do things. These teams consider their stakeholders their customers. Every week or fortnight, a project manager solicits tickets from stakeholders. They put them in the sprint planning for discussion. Then the team designs and builds that. The person may have the product owner title but they are managing projects at this stage.

This is a serious problem. Innovation rarely happens in this model. Unless you’re working on an internal tool, the stakeholders are not your customers. If you’re working in an industry where you cannot get access to your users (hard to imagine, but let’s assume), then the stakeholders may be a proxy for the user. 

Stakeholders are very important and they are not to be dismissed. They represent constraints. Managing whether the product works within the constraints is a key part of the PM role.

But it's important to remember: stakeholders are a partner to the team. Not the customer.

Get Real

So, what does it take to be real?

To work like a real product team, there has to be personal growth and an increase in responsibility. It's very much like learning to swim on your own.

The PO moves to a PM role, i.e. takes more responsibility:

• Strategy
• Vision
• Stakeholder Management
• No longer just admin for the backlog
• They come up with the backlog instead
• Not something they teach in Certified Scrum Product Owner classes

Designers needs to become a “true designer”:

• Not just about pixels anymore
• Service design skills
• Proficient at making various prototypes
• Research skills

Engineers need to step up and at least one has to be a tech lead.

The rest of the business & the leadership team need to:

• Give the team product vision at a product line level, or a business level
• Give them objectives
• Give them a chance!

If you liked this, give it a Like - it'll go a long way!

If it wasn't something you cared about, send me a DM so I know what you do care about.

And if you have some counter-arguments, let's talk about it - we only get to the truth by communication.