This article was originally published at Medium on Jun 27, 2020
Over the number of years, there has been an enraging debate on whether investing significant resources to define a complete architecture makes sense, while product decisions still need to be determined and carved for readiness. Introducing iterative delivery framework is immensely helpful but also becomes increasingly difficult to understand and map the business expectations, however granular they might be, versus the architecture decisions to be made to provide value to the customers. In essence, architecture is about trust.
The product manager collaborates with stakeholders to understand their features and pins them down on benefits of feature requests, the stakeholder expects their features to be delivered, exactly the way they have in their head, and architecture is supposed to understand all the business priorities, that might come up during design phase, and make sure they all can be accounted for any opportunity that hasn’t been unlocked or realized yet. I know it is a worded statement but a perfect case for Catch-22.
Value Proposition isn’t linear.
Unlocking customer value is harder than it looks. There is an unlimited amount of permutations and combinations that can uncover a value proposition. Millennials, Gen X, Gen Y, Baby Boomers, and realize value radically different than each other. Let’s take an example of a drastically simple example of purchase pattern:
Baby Boomers: They won’t trust the product until they feel it themselves. More importantly, the reputation and longevity of an outlet matter to them deeply. In many cases, they might be buying from the same mom-and-pop shop even if this point of sale hasn’t upgraded their offering. Learning here is not to radically modify their experience. Whichever product line you might be working with, if they are your targeted audience, these will struggle the most and could eventually become a target of the less-savvy-more-copy-cat product line offering from a competitor.
Millennials: They are less motivated by the perceived value of the product but more focused on the value proposition of their intended purchase. Is the company socially responsible? Does the sustenance outweigh an artificial value of the product? But, don’t make the mistake of all the Millenials being the same. They also value the celebrity value of the product. Are their influencers attached to the product? Fyre Festival got it right (at least, that part) by using their social influencers to promote something humanly impossible. And it worked, and Millenials showed up.
“While Fyre itself was a disaster, the marketing choices behind it were not. It just shows how powerful influencers can be.”
-Rohan Midha, PMYB
Gen Z: They are a notch level above Millenials. While they follow most of their principles, their brand loyalty is close to none. They respect the brands for what they represent, far more than how millennials look at them. The brands should be authentic, not copy-paste from other products with similar offerings, and should uniquely reflect on Gen Z’s personality.
Now, I might seem like I‘m’ slightly deviating from the topic; these underpinnings are far greater than just designing a product. Imagine designing experiences with product managers and then architecting them in an evolving phase while keeping your targetted generation(s) content and connected.
From Point A to B — Consistently.
I won’t call myself savvy in chess, but I am constantly amazed by the powers of the queen in this mastermind game. While king could make you lose the game, often losing her during any point of the game is inching you closer to defeat anyways. The market is stacked with products, willing to offer the most bang for the buck to your customers. The focus is on features enablement, but it is expensive to lose sight of CX. CX isn’t just about UX; it also ensures that your customer can consistently complete their intended journey all the time.
Product features continuously evolve and aim to provide a rich experience to the targeted audience. Amid this value proposition, architecture scalability justifies its importance in terms of gaining an edge with your customers. Everyone loves to give an example of Amazon, so let’s take one from that page. I have rarely seen my journey interrupted while browsing for wonderful gadgets (that I rarely need but still buy them). Is their CX perfect? Heck, no. But is it consistent: I’d repeat: Hasn’t interrupted my intended journey (yet). But having a Subaru, running reliably and predictably, is much better than a Ferrari breaking down often. Well, unless you have a lot of cash to burn.
Scale It or Nail It
There is always a battle between building features vs. scalability: Product Manager consistently keeps it in the back of their mind while driving CX and adding features to a product line for themes and Architecture is constantly battling with technical scalability of the underlying codebase supporting the product line. But scalability is a dual-faceted. There is often a cascading effect of not starting with a scalability-first approach, but it should also be done analytically.
When a Feature is being dissected, two most important roles should be present and actively participating (other than a product manager): An Architecture SME and Principal Architect leading the feature team. Why two architects? Doesn’t that sound like overkill? Let me attempt to convince you.
Architecture SME: By definition, this individual drives the strategic direction of the product from a technical perspective. They are worried about Enterprise Scalability to be able to offer products in multiple facets. This is critical because it sets the GPS to the desired destination strategically. Let’s elaborate on this with a specific example. When the product is in envisioning stages, the market segment is identified along with the delivery mechanism. If you product is specializing in digital delivery, you have to be conscious of platform selection, revenue models, delivery modes, and, more importantly, the future path of evolution of the product. Knowing this, even at a 30K foot level, guides the Architecture SME to get into tool selection with a focus on future scalability. It doesn’t need to be addressed today but cannot be ignored, either.
Principal Architect: Just like a wine sommelier knows more than just the wine, they can also advise one in pairings. These architects understand the underlying technology, powering these features extremely well. They can lend their expertise in advising in possibilities and also making the right decisions to account for scalability. And it just doesn’t end there — Consider them as an expert that pairs with technical delivery teams to ensure this scalability embeds in the heart of the implementation. Think in our earlier example; the beta product should be identified and implemented with strategic guidance from Architecture SME. So, if a mobile device is the focus area for launch, but it also has a Desktop delivery mechanism in the future, you want to ensure that your functions will be available and compatible with additional platforms on the roadmap. I’ll end this article with a great quote from the lead programmer of my favorite childhood games (Quake, Doom).
The cost of adding a feature isn’t just the time it takes to code it. The cost also includes the addition of an obstacle to future expansion. The trick is to pick the features that don’t fight each other.
– John Carmack
PS: It would be unfair to end this article by calling a winner: Gist of it is that they both are. You cannot ignore one while continue to build castles on others. Features are as important as scalability and vice versa.