How Product Managers and Product Architects interact, matters!

6 min readFeb 24, 2022

TL;DR

A Product Manager and a Product Architect: both are amongst the main stakeholders of the product. While the Product Manager puts herself in the shoes of users of the product, the Architect puts herself in the shoes of implementer. One complements the other and drives success of the product. Therefore, the modalities of their interaction must be effective, tractable and goal-oriented.

Preface

My lucky and long association with software product companies from the very early years of my career, has put me me right in the middle of professionals who are product builders. The way they think, position, build, and validate products and then carefully let the products evolve — and carry along the happy, praising and paying customers — has been source of limitless learning.

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

It helps if the architect — responsible for materializing the solution — is brought in the huddle, during the conception stage. During those sessions of hand-waving, white-boarding, quick-notes-taking, screen-flow-sketching and cross-talking, a lot about what is expected to happen, is said, probed and assumed. The ‘why-s’ are floated and the ‘how-s’ are noted. As the things above the hood get the focus, the things under the hood take shape too. This doesn’t necessarily mean that the architect commits herself to a technology stack but a picture of what is intended to happen, slowly emerges. Seasoned software architects know that such diffused thinking helps form a mindscape. This mindscape is where the intended architecture germinates. Relevant queries and their clarifications are collected. Knowns and Unknowns are identified and bucketed.

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

Domain terms signify how real world actors/entities in that domain, interact and influence each other. These terms pack a lot and carry meaning and context. Ultimately, a software solution is a computation model that is meant to complement the real world’s goings-on. An architect, aiming for that solution, has to begin with what happens in the real-world and how. The seeds of software architectural elements — which will embody these what and how — are sown in an architect’s blueprint, as Product Manager introduces and elaborates the 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

The architecture of any non-trivial application always evolves (Sacrificial Architecture); primarily because the business environment changes and as a result, do the expectations/demands from the solution. If the original solution is successful and is helping bringing in new customers, it is quite likely that these new customers will ask for new, valuable features, hitherto unconsidered. The question is: will the current software be able to accommodate the new demands, and if yes, then how does one know what is the additional work (effort/cost/time) required.

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

The very nature of today’s Whatever-As-A-Service drives one to the cloud-based arrangement of the software. To most of the Product Managers (if not all), this is a given. However, it is equally important to recognize that by running multiple independent components on the cloud, one is also embracing complexity of a distributed software system. Much of this complexity is accidental in nature, and affect the solution’s design, development effort, deployment drills and operational characteristics. As Leslie Lamport warns sagely: “A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable.”.

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. )