How Product Managers and Product Architects interact, matters!

TL;DR

Preface

I have seen that accomplished Product Managers / Product Owners (used to refer to the roles interchangeably here; no nitpicking with Agile purists here) spend a lot of time in:

  • sketching,
  • elaborating,
  • preparing questionnaires,
  • bringing Subject-Matter experts (as appropriate) into discussion,
  • proposing a proof-of-concept and
  • taking interest in what the DEV(elopment) or ENG(ineering) — used interchangeably — team has to say about the feasibility, effort, complexity involved and cost projection.

It had been and still is, a joy to work with such Product Managers.

During my many interactions — as a hands-on [Architect](The Architect Elevator — Visiting the upper floors) (used strictly to refer to a role and not a designation or indication of hierarchy, and even may be represented by a group of people) — with Product Managers, I have observed that the effectiveness of these interactions, remains understated (not always, but for a very significant number). The outcome of these interactions has a profound impact on the success of the product.

Here is a summary of what I want to submit to Product Managers, to make this interaction, effective, complementary and fulfilling:

Engage the Architect in the discussion from the onset

All these set the ground for arriving at future Milestones and Timelines. These two are indispensable for the Product Managers, as they will attest.

Make the architect comfortable with meaning and context of domain terms

To the Product Manager of a solution in the world of automated-supply-chain, a simple query like ‘’I want to find out what is the status of a moving truck?”, is a lot more to an architect’s keen eyes:

  • What is software model of a moving truck (that cute roving picture on your mobile phone is only small part of the story) in the solution?
  • Is status, just the geo-location? isn’t the driver’s name is a part of the status of the truck? Will the distance remaining to cover, to be included in the status?
  • What is the frequency of such queries?
  • Will the status be pulled by person making the query or pushed to the person by the software?

Or,

A Product Manager of an online training/skill-building service, surely needs to keep track of a student’s lesson-plan and progress. To a seasoned architect, probes like the following harvest very useful information:

  • Will there be a template of such a plan? If yes, then obviously, a facility of ownership and versioning should exist, along side (may be as mere placeholders, at the beginning).
  • Will there be a minimum and maximum number of lessons in a plan? The edge cases, ways to handle them and default behaviour etc. are important inputs.
  • Will there be a set of rules for a student to be eligible for the next level? Quite likely, there will be and it is possible that the Product Manager hasn’t thought about the exact rules yet. Having a computation model where every lesson has two gates: entry and exit criteria, is an excellent preparatory step .

So on and so forth.

Such questions and answers (or, even absence of an answer) are often significantly undervalued input to an architect.

Acknowledge the value and life of a Proof-of-concept

In some cases, accommodation is easy. In many cases, though, some scouting is necessary and advisable. Topics like adoption of an authentication mechanism or integrating with 3rd party software or handling much larger set of data than anticipated initially, are examples. A PoC can unearth potential complications much earlier in such cases. Being forewarned is forearmed!

A PoC can begin with a visual screen-flow and end with a few computation nuts-and-bolts behind: together, these can form piece of executable code that helps in assessing what is achievable, along with the development effort, time frame and budget. Product Owners do and will find these very useful! A working code, matters!

Sometimes, it is more useful to create a Reference Architecture (Reference architecture — Wikipedia) . Put simply, a Reference Architecture is a miniature solution which demonstrates how core components are expected to work together and behave . A Reference Architecture is a very effective spring-board for the development team and can even be a ready-guide for arriving at Buy-or-Build decisions.

Consider NFRs in the light of distributed nature of the solution

For a Product Manager, the Non-Functional-Requirements — colloquially referred to as the -ilities (Availability, Reliability etc. ) — are crucial determinants of the product’s success. Enumeration and validation of these ilities are a part of an architect’s primary deliverable. Ensuring that NFRs are indeed satisfied in a distributed, networked environment is a non-trivial task. Various errors and edge-cases remain unforeseen till these hit us on the face. While an architect elaborates the likelihood and manifestations of these error conditions, a Product Manager decides the way an user is guided when these conditions occur. At the end of the day, an user doesn’t care if the product is running on-premise or on-cloud or if the data is fetched to her synchronously or asynchronously. The product’s predictable behaviour and avoidance of surprises are what she values.

Needless to say, this list above, is very much influenced by what I have seen and been exposed to. Others must have different experiences. Please share your views (critical? even more welcome!) and educate me.

(I work as a freelance platform technologist with a consortium of consultants: Swanspeed Consulting. )

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Nirmalya Sengupta

Philomath, professional programmer, looking for tech opportunities to help make stuff that works, Indian but Citizen of the World, loves History and Geography