Customer Inspired; Technology Enabled – Product Tank Wellington MeetUp with Marty Cagan

The Product Tank Wellington meetup ran a really cool session recently called “Customer Inspired; Technology Enabled” with internationally recognised product guru Marty Cagan.

As you can imagine, someone of Marty’s calibre provides a lot of great wisdom.  Some reinforced or reinvigorated stuff I think I already knew, but much was also new.

Here are my old-school hand-scribbled notes (2 pages) if you’re interested (or neglected to take your own, tsk tsk): Customer Inspired, Technology Enabled with Marty Cagan – 12-Feb-2018 – Adrians notes

Note to anyone doing architecture: broadly speaking, anywhere it says “product” I think we can swap with “solution”.  Which is why I’ve tagged this #ArchitectureInTransformation – architects need to (at least) be mindful of this stuff.

Also, in this context  when we talk about “product” we mean a technical product of some kind (i.e. software/technology related) – not something like floor polish or mint scented vacuum bags.

Key Takeaways and Gems

Asking customers what they want

If you’re looking for where to take your product, the short answer is “don’t”.  Instead, invest your time in asking customers about their problems.

You should not rely on customers to tell you about which direction to take your product, or what new features or capabilities to add, because:

1. They don’t know what’s possible – they generally aren’t technologists. (The clever technologists should be the people on your team).
2. Great (new) ideas have to be discovered.  For me personally, Marty was making a strong connection to empiricism – in that you can’t rationalize your way to a “new” idea.

The way to flip the question is to be to ask your customers about things that they do know about: their problem, their constraints.

Another reason why you can’t reliably ask customers what they want is because they themselves don’t actually know what they want until after they’ve seen it.

Engineers

Marty spoke repeatedly and at length about the importance of involving engineers in the product process.  He cited several cases where new successful products had emerged from the techies – essentially from random ideas they had on the fringes of a project, where their inventiveness (based on their deep understanding of the technology) led to something entirely new.

He suggested giving developers time for discovery – something in the ballpark of half an hour a day.

Overall his message was clear:

1. Work with strong engineers that are passionate about your vision.
2. Do not shelter them – expose them to the full business context; expose them to customers.
3. Provide them with constraints, not requirements.

Requirements First?

Speaking of requirements (whilst talking about agile) he neatly flipped the old Analyse > Design > Build model around:

1. Knowledge of the technology…
2. > enables design…
3. > drives desires/needs/requirements

Essentially this comes back to the same point posed by “asking customers what they want” – if customers don’t know what is possible then the requirements will always fail to get the most out of what the technology is capable of.

Are you Agile?  Really.

I had to laugh – Marty’s position on Agile was that it’s a no brainer, like why are people even asking this question.  And it wasn’t just the words that gave me a wry grin, it was also his tone: dry, cuttingly sardonic, with a hint of tactful incredulity and thinly veiled loathing.

Point is, there’s a difference between thinking you’re agile and being agile.  Try these two refreshingly straightforward questions:

1. How soon can you test?
2. Does shipping out a release mean you’re finished?

The correct answer to #1 is that if testing is done at the end, it’s too late; if you’re agile you’re testing as early as possible and not just at the end.  If you only test at the end, then that’s where you are putting all the risk.

#2 Is a really key one; it’s about the difference between releasing something and solving a problem.  The common misconception is that when you’ve put out a release, you’re done; but whilst getting stuff delivered is great, you’re only actually “finished” if you’ve solved the problem you set out to solve.  Shipping out a release merely gives you an opportunity to see if you’ve really solved it.

So, if you iterate – great; iterate, test and keep shipping until your target problem is solved.

Roadmaps

Much of Marty’s talk sounded like heresy… in that it would certainly sound blasphemous to many people I can think of.  His discussion on product roadmaps was no exception.

Roadmaps tend to assume that 100% of the ideas on them are good ideas.

The reality is somewhat different.  Marty cited Google: in their experience, for every 10 ideas they have (on a roadmap) only 1 tends to pan out.

Bad use of roadmaps relate back to the second point in “are you agile?” – in that people sometimes confuse delivery with completion.  People walk around with roadmaps and release schedules and focusing on getting stuff delivered.

So if that’s all wrong, what does right look like?

Essentially it comes back to having a strong product vision.

My notes on this part of the talk are scarce – a sign that I was either too deeply engrossed to write, or I agreed with what he said and felt no need to note the obvious.

In either case, the key takeaway for roadmaps takes heavily from the points above: focusing on the product vision – which I think we can safely extrapolate to:

1. Understanding the customer and their problem.
2. Giving your teams constraints and time to come-up with the unexpected.
3. Iterating until solved, not just shipped.

Roadmaps and Agile

From a philosophical perspective, roadmaps are rational – they plan out what is to happen; whereas agile is empirical – it learns from what has happened.

Roadmaps attempt to answer the fundamental questions: how much will it cost, and when will we get it?  And as Marty acknowledges – that’s not an unreasonable thing to want to know.

Agile can answer these questions but only once you’ve done enough work, to provide enough meaningful experience, on which to base a forecast.  Marty elaborated on that theme in terms of a “high-integrity commitment”.  I don’t have any notes on that so allow me to refer you to Marty’s blog:

• https://svpg.com/managing-commitments-in-an-agile-team/
• https://svpg.com/the-alternative-to-roadmaps/

Teams

• Measure teams as a whole; not in terms of “functional” teams, but product (solution) teams.  (What does this mean?  Think about the difference between “shipping” and “solving” and you’re pretty much there).
• Provide teams with a competent and confident product manager.

Product Managers

The final subject I want to cover is around product managers – specifically good ones; it’s important to me because it’s highly relevant to what I see as a architect in solution-architect / domain-architect / enterprise-architect / consultant space.

Marty placed a lot of emphasis on the importance of having a good product manager.  For him the product manager is like the “CEO of the product”, where CEO refers to the calibre of the person in that role, and because good CEO’s know all the elements of their business.

Product managers need to be smart, creative and persistent.

The product manager should must have a deep understanding of:

1. The customer(s).
2. Industry trends.
3. How your business works.

The reason you want a good product manager is because this is type of invaluable knowledge and wisdom they’ll bring to your team, and to your product.

Advertisement