When and how do product managers in your company collaborate with engineers, UX and the business? Is products first interaction with engineering or UX in iteration / sprint planning? If so they have fallen for the classic product manager mistake I call "the lone ranger".

According to Marty Cagen product management is the epicentre between "Value, Feasibility and Design". Martin Eriksson translates this to being the middle point of "Business, Engineering and UX". These three disciplines are referred to as the 'triad'.

The triad collaborating is crucial to product success. The triad does not have to be three people it may be more or fewer but it must represent the three functions with confidence. 

Product managers I have coached typically fail to collaborate early enough. This results in a failure to identify core assumptions for validation early on in product discovery. Overlooking assumptions wastes a lot of time and in some cases encourages product to accept a less valuable proposition - sometimes to save face but often because there is already strong emotional investment. 

The triad does not need to be present for all of a product managers effort, the collaboration starts at the very beginning and typically increases as more is learned about the problem and value proposition there are increased returns for greater triad engagement. 

Product Managers must collaborate to capture great ideas, learn about the problem and identify the right features to build. A lot of great material has been authored about product talking with the customer and 'getting out of the office', but less focus is given to encourage product to talk with the triad. 

In his book User Story Mapping, Jeff Patton proposes using the triad to break up "product" user stories which are normally quite large into smaller bite sized stories. While I agree with Jeff, some organisations fulfil this through a kick off process at the time of writing user stories and estimation without any previous collaboration. This is not enough! A lot of product work should already have taken place. The triad collaboration should start at the beginning of product discover and strategy.

I have experienced product managers challenge early triad collaboration as encouraging big upfront design, suggesting it is not agile. If executed poorly it can be.

Typically it plays out that its takes 2 to 3 weeks for product to validate, prototype, improve and learn what needs to be built and 4 to 6 weeks for a delivery team to build it right. Obviously this is a rough guide.

Who is in your triad? When does it form? How often do you collaborate?

AuthorDave Martin

Ten years ago it was typical that only system architects uttered the phrase API. Since 2005 the programmable web has exploded from a handful of open APIs to thousands of companies exposing functionality for developers to harness. Firms like Salesforce and eBay enjoy more than half of all their transactions via their API while social networks such as Twitter experience well over 10bn API calls a day.

Exposing an API helps organisations deliver more functionality and achieve faster times to market. The API allows businesses to use the best of class existing services and focus on delivering customer value, for example catalog management, rating providers, shipping carrier integration, pricing engines, inventory systems, payment gateways, social integration, recommendations, image manipulation, video streaming, ticket booking, etc, etc.

The business benefits of building an API depend on context and focus but include…

  • Customer innovation,

  • partner network development,

  • increased sales conversions,

  • professional services revenues,

  • speed of development,

  • and user acquisition.

The business of APIs is huge and many successful multi million dollar firms do nothing but operate an API such as Twilio.

Probably because an API has no traditional user interface and is consumed by engineers many organisations make the enormous mistake of failing to invest in API product management. This results in API initiatives that deliver low or zero business value.

API product management has to focus on two key personas:

  • Engineer / Developer who will consume the API.

  • The users of apps the above engineers build.

Product managers need to fully appreciate the pain points the engineers face to consume the API. If the API uses unusual protocols or forces the engineer to ‘jump through hoops’ they are less likely to confirm to management that it is feasible to integrate your API.

If engineers inform their management your API is poorly designed and will take many man hours to integrate, management are more likely to de-prioritise the work or suggest the engineers look for an alternative. The engineers consuming the API are your key stakeholder and customer.

AuthorDave Martin

Many product managers depend on evidence or analytic data to make winning product decisions, how many times does the improvement go live and fail to have the desired impact? Why is it that great product managers consistently deliver improvements that move the needle?

I recently was reminded of a anecdote where a maths teacher plays a simple game with their class. The teacher sets out a challenge, he has a rule which results in a sequence of numbers "2, 4, 6". The pupils can make as many guesses about the next numbers and the teacher will answer with "follows the rule" or "breaks the rule". The pupils can only have a guess the rule once.

This feels very similar to product managers using analytic evidence to validate their assumptions about a new enhancement.

The first pupil guesses 8 and the teacher replies "follows the rule", the pupil then guesses at 10, the teacher again replies "follows the rule". Feeling confident, the pupil guesses the rules as being "add 2 to the previous number". The teacher says "No that is not the rule."

The pupil obtained evidence that showed his assumption as being correct. Pleased with positive results the pupil made the common mistake, they failed to validate their assumption by attempting to break it. We typically look to prove we are right, instead of proving we are wrong.

A different pupil, unaware of the incorrect answer, also had a hunch the rule was add 2 to the previous number, they also guessed 8 and then 10. However, instead of guessing the rule, this pupil then guessed 13, the teacher responded "follows the rule". By attempting to break his rule the pupil discovered his assumption was wrong - 10 add 2 is not 13.

He had another idea, so guessed 10 (so the sequence is 2,4,6,8,10,13,10), the teacher replied "breaks the rule". The pupil then guessed various numbers lower than 13 and then numbers bigger than 100 getting larger and larger. The pupil then offered a solution - "The next number has to be bigger than the previous number", the teacher congratulated the pupil on getting the correct answer.

When product management validates assumptions there is often an eagerness to find evidence that the assumption is correct. This results in the common mistake of product enhancements being invested in which will deliver no additional value or return. 

Great product managers validate their assumptions by looking for evidence to show the assumption is wrong. This approach results in more enhancements being developed that increase value. It also encourages a culture surrounding product that failing quickly is good and improves our understanding. 

AuthorDave Martin