The Product Management Interface - The Architects

This is third in the series of PM interaction with internal teams. The Architects tend to look at the engineering competence of the organization, build engineering capabilities and make sure the company's technology is the best in the market. It's important for a product manager to involve engineering early and ensure the larger context of the product is understood and internal capabilities are built before actual delivery cycle or the build phase of engineering is carried out. A typical architectural involvement in a project must be carried out in the planning phase only.

The Common Sense Trap

Most people who tend to appreciate average skill of engineering tend to focus on common sense and get the engineering into a common sense trap. I will state a few examples here to describe why common sense is a trap and you need a little above common sense to excel in engineering. I will discuss 4 geometry problems and their common sense implications and not so common engineering interpretations.

Problem 1 - Point Coincidence

Given two points A and B in 2 dimensions, we will like to know if the 2 points are the same.

Common Sense Interpretation - If Ax = Bx and Ay = By, Then we know A = B. This is what your average engineer will code.

Computer Scientist's View Point - Fixed bit floating point numbers cannot exactly represent all numbers. They have rounding off errors. For example, a number like 0.1 decimal does not have an exact 32-bit binary representation in a computer. Just like 1/3 does not have a fixed decimal representation. It's a recurring number of 0.333333333333333... So if you did a few computations to arrive at number Ax or Bx you will definitely be off from the ideal values. So equality does not hold. So a typical computer scientist would say:

If distance(A, B) < pcTol, then A = B. pcTol or Point Coincidence tolerance is considered a fundamental computation premise in most CAD, graphics floating point systems.

Problem - 2 - How to know if triangles 3 points form a triangle?

Common Sense Interpretation - We know triangle has 3 points. If any 2 points are coincidence triangle cannot be formed. So, if distance(A, B) > pcTol or distance(B, C) > pcTol or distance(C, A) > pcTol, then triangle cannot be formed. Does this mean if: AB = 10.0, BC=20.0 and AC=10.0, it will be a valid triangle. Answer is wrong.

Common Sense+ Interpretation - Sum of 2 sides of a triangle has to be greater than the third. And, that leads to the statement equals(AB + AC, BC) in the earlier case so triangle cannot be formed. But what if AB = 10.001 and AC = 10.001 will that lead to a valid triangle?

The CAD Triangle Area test - Although, in most cases the sum of 2-sides is a good enough metric, it does not really tell you how the pcTol you accepted as the fundamental of point coincidence related to the triangle. If you look closely, while AB, AC or BC none of the values are anywhere close to pcTol, vertical distance of point A from the line BC can be very small due to the lengths of AB and AC relative to BC. If assuming the vertical projection of A on BC is D (AD can be smaller than pcTol). So for a CAD engineer, the triangle area test looks something like this:

max(AB, BC, AC)*pcTol > 2*area(ABC) means the triangle is invalid

Corollary 1: 3 points are co-linear when they do not form a triangle

This is directly coming from the principles discussed in the problem 2.

Problem 3: How to find n-points are co-linear?

Common Sense Interpretation: Well once I know 3 points are co-linear, I can consider 3 consecutive points together every time and check if they are co-linear and if all such points are then they form a co-linear set of points. Unfortunately, the answer is in the negative. The actual solution will be to check all 3 point sets and compute co-linearity. But if you have n-points your complexity will be n^3. Absolutely, sub-optimal solution from computation standpoint.

Computer Scientist Interpretation: You would be surprised to note data scientists use this all the time with principle component analysis. So they will try to fit a line through the n-points and measure the distance of the line from each of the point. If any of the points are above pcTol, then the points are not co-linear. In fact, cross correlation of multivariate analysis under ANOVA is in some sense related to a similar concept. But that's not relevant in this context so we stop here.

Problem 4: Find one point which is definitely inside a polygon.

We all know polygons comprise of infinite number of points. What we are interested in is one point, that's guaranteed to be inside the polygon. Seems just picking up one from infinite right? Well think over it. Polygons can be concave, can have holes in them. The solution has been stated here: http://erich.realtimerendering.com/ptinpoly/. You are a born CAD architect if you could arrive at the solution without looking at the solution.

Why Architects?

You must be wondering why I was discussing 2-D geometry and seemingly naive puzzles. The 2-D systems are most common geometry we deal with day-to-day interactions. We have studied them for almost 12 years of education. But when it comes to implementing any reasonable programming in CAD, there just does not seem to be any reasonable answers which does not cloud our minds into lots of corner cases. Common sense fails. Common sense is good enough for most problems but if you want to differentiate even a little bit in the market from any reasonable competitors it's best common sense trap be avoided. Good architects help you avoid those traps. Most serious organizations have architects who tend to be people who have industry level contribution in the domain or close to making those transitions by making their presence felt through patents, industry articles and standard bodies etc. There are software architects as well, who have understood and designed large scale systems that has been deployed in the market. They also contribute significantly in designing systems for scale and operational excellence. Sometimes, there are engineering leadership who play roles are architects to build consensus in teams. I will not discuss about them in this section as their roles are mostly part of engineering interface. In simple terms, the title does not truly matter. The level of technical competence a person brings in what defines an architect.

Engage the Architect Early

The PM is too focused in understanding the customer problem and has some understanding of the possible implementation but may not understand engineering feasibility. Defining workflows which are not aligned to engineering feasibility creates problem statements that do not lead to any reasonable solutions. With AI and Machine Learning being integrated into lots of newer systems the dependency has in fact grown further. These fields mostly require higher order mathematics and statistics that may not be within the purview of an engineer of average skills. An architect can quickly identify those complexities. Being aware of the internal engineering capabilities can reasonably estimate the complexity. If needed can guide the product management to request for building or acquire the skill set to develop the organization capabilities.

Outside In View of the Latest in Technology

Second aspect that architects bring are an understanding of the latest in technology that will be needed in the product to support the next generation of products. For example, the newest of web technologies, the latest in REST APIs or Web Services. Things like this do not directly impact the customers but there is an in-built requirement to upgrade to ensure the product is maintainable in the future versions of the operating systems. The performance and scale requirements as your customer use cases grow is another continuum of improvements to look into. Upgrades, remote deployments are some of the standard day-to-day use cases that have a direct need for architectural inputs though customers do not explicitly request for them.

How to Apportion Architectural Requirements?

It's always important to develop a portion of product backlog for the architects to fill in and continuously assess their immediate requirements and capacity requirements due to those changes. From a feature value perspective, they definitely do not add a straight addition to the product needs but they are definitely what are needed for ultimate success of your product. Hence, there has to be some portion of development cycle maintained for such activities. No PM can approve a pure bug fixing, stability or architecture enhancement release. But, every release can have a few of those under product sanity improvement.

The Engineering and Architect Barrier

In most product organizations, the architect reports into the engineering management but the scope of both roles are different. While architect is focused on the eventual quality, longevity and scalability of the product, engineering is focused on timely delivery to an agreed upon quality metric. Any change to the interlocked scope is kind of frowned upon. In some sense, architects sometimes get into locking horns with their immediate management. And, may find themselves in a situation of limited help. PMs sometimes need to assess the organization dynamics and impress upon engineering leadership to support a larger cause for the product accepting scope creeps and schedule deviations.

Conclusion

Product architecture is an important consideration for the longevity and success of a product. Architects add to a significant part of that. As a PM it's important to understand the importance this interface and look beyond the immediate release needs. And more importantly work closely with the architects to ensure the success of the products.