Product transformation

• Are engineers involved in the roadmap design?

• How much of decision making minds do take intellectual assistance from engineers?

• How do we ensure that we invest in the intellect right? How do we strategize such that the return of Investment should be the motivation toward a common organizational goal.

• Is it the entry gate to the minds that become a part of the product team that needs to ensure that we get the minds that can invent/discover or someone who cannot go ahead without a purpose?

• For instance, I cannot do a thing without a purpose being told to me, or is something that is self-explanatory?

• Because, if an engineer is asked to build a button upon clicking which an API call is made and the engineer does that with no further questions, then I guess that is a sign of ignorance and the product or the solution offered via the button is devoid of value. Because,

1. The engineer didn’t bother to ask why the button is clicked and what the API call is all about? Or what the business impact of clicking that button is? Or why was the button not there before?
2. Lack of motivation to make that button click a better experience by putting themselves in the shoes of the end user of the button.

Button here can be interchangeably used with any Product Backlog Item.

Product Discovery: Ways to discover problems to solve and build solutions.

Raising the bar on product managers: Would that do something?

How about the motivation to do something.

Autonomy

It may look like we are building and expanding our realms of reuse such as the platform team. But, if that is growing into a structure that thwarts our own growth through unnecessary check points, do we need to draw a line or learn to draw one that could help us drive autonomous teams that can create, innovate with no limitations at least from the infrastructure stand point and inter team dependency resistance?

Do we need an easy channel of connection that can be established on the fly between an engineering mind that has an idea to solve an important problem for the business. Because, ideas get lost in vain when not heard, right?

Understanding anything when it works or when it doesn’t, on why it did or didn’t would give us a good idea to build a controlled solution. Otherwise, it is more than likely that the small void of understanding around why something worked, we try repeating the process blindly to have it working and expand it without limits to grow to a size where it no more is helping reusability or can be broken down into independent parts bringing us back to the same place we started to mobilize by having smaller moving parts that have their degrees of freedom of movement.

Following is from the Product Driven Development Blog draft.

Here’s my initiative to inculcate product driven thinking,

• We need to include the “VALUE” that gets added to the organization, even in the smallest of the efforts we put into the tasks that are assigned to our resources at every level. How did I realize this? Inquired and discussed with team members from a few teams that have their functional documents and product backlog items defined. It was not shocking to learn that there was no VALUE being mentioned in the work item descriptions. And hence was I able to also infer from their responses that they had not a great sight of what they were contributing toward.
  Let’s take an analogy. If the end resource who is working on a task of building a brick, without being aware of the building or the structure they’d be contributing to, it would be any brick. Nothing to claim or acclaim. But imagine, the same resource was aware of the contribution they’re making and the building was a hospital that their own family members would be visiting for health care, we would be shocked by the difference it made to the same old brick that was being made by the same resource. Motivation is important. And, most important is the purpose that manufactures the motivation needed.
• Missing this, would make the outcome, target the local maxima; instead of the global maxima, which is possible only when the resource acting on this item is provided with, or is aware of the overview of the bigger picture that they’re contributing toward and hence the impact of their time and mind invested in doing the same. That would be the time in near future, when we would start building something of our own. I can imagine each person thinking from their side in the shoes of not their task, not their team, not their vertical, but of the Organization.
  Here I’d like to add a small anecdote – it is a well connected one. We are currently hearing from the PM teams to know more about the CPU utilization factor in real time, as the teams are afraid to run short of CPU or the processing power, which in fact drives a lot of conversations in my mind. One of which is that, how can we ever run short or CPU or have the utilization levels reach alarming levels (could be any threshold set by the app team) with the currently available scalability, both horizontally and vertically.
  That being said, if I can think of even one reason for this to happen, it is definitely the amount of time a piece or code or a block holds the processor to itself, which is driven by the amount of data that is getting processed at any point of time per process’ call to ask the scheduler, for the processor’s time.
  This has led to, in many situations, to fall back on the approach where, the teams reach a position to make a decision between choosing a feature delivery (which is our monetization factor) versus code refactor to optimize the performance that usually involves breaking changes, alongside of which we also blindly lean on the horizontal scalability due to resources being on cloud and containerized.
  If we had to determine if this is a healthy route or a detrimental one, we would have to consider the effects not at the moment or a week or a month later but in long run, what are we building? A problem whose solution to optimize the code base is overshadowed by scaling both in power and number of instances, while the problem underneath can easily snowball.
  Therefore, it is always appropriate to understand and resolve problems at their root levels. As a result, we could attain Global maxima instead of local maxima(that would be later discovered as something that needs to be replaced, with a more elegant solution). TIME AND MONEY BEING WASTED, otherwise.
  
  Just imagine: Instead of the solution route we had ourselves follow (to just add more resources on cloud to cater to the increased CPU utilizations), if we tried understanding the WHY of the problem, in a few WHY(s) we would reach a point where the code written was not written keeping in mind the increase in the size of the data to be processed.
  As simple as saying that, there should have been no block of code whose time complexity grew with the data size.
  10,000 records to process to begin with, costing 200ms – Marked Awesome.
  After a while, it got to a 1M records and the time complexity increased by x100 folds resulting in 200msx100 = 20,000ms = 20s
  Why did this happen?
  Because, the developer who wrote the piece of code didn’t consider the data to increase by this factor when written.
  Why again? Because, the developer was given a user Story or task that said, write an API service method to process digital only payment transactions from clients in that last 10 minutes.
  Why again? What is wrong with the requirement? It fails to signify the value of the work being done here. It is devoid of the practical implication of the word Clients and the impact it would have with the growth of the client base.
  Why? Because, the developer was not communicated about the value that would be added by this piece of functionality.
  Why? Because, the team lead only received a requirement from the PO to have an API to process payment transactions.
  As a result the developer did implement the requested feature: to process payments that were initiated in the last 10 minutes, regardless of the number of payments.
  And hence when the number of payments to be process over the same time span grew drastically, the API couldn’t handle all of it.
  Hence locked the processor for itself and ran out of it very soon.
  
  Instead, if the PO communicated the value of the task being created, an further the same information conveyed to the developer,
  the API could have been written in a way that it is agnostic of the data size and would only fetch a pre-defined block size of data to process at a time. Thus would never run short of processor time or memory.
  This time it would be fetching 10000 records no matter what the total size of data was, be it 1M or 2M.
  To satisfy the SLA around the same, we could then have sharded the processing across instances and gotten them all processed in time and never out of time or processor power or storage or memory.
  How is this possible? By communicating the value embedded in the task.
  How is this possible? If the Team Lead conveyed it to the Developer.
  How is this possible? If the PO conveyed the same to the Team Lead.
  How is this possible? Did the PO not know of this value before? Maybe, they did.
  the point is that, communication of value should not be a probability that is tied to the effectiveness of communication of the PO.
  Maybe, the PO was mentally upset that the Starbucks coffee ordered before the meeting with team Lead and hence couldn’t convey. But, how does that turn out?
  Who is impacted now? How big is the impact? BIG is the answer.
  
  Therefore, instead of relying on the unreliable aspects of a human, we should rather make it an integral part of the work being created.
  That way, being effective is not dependent on any unreliable factor such as a human error.
  Making value a part of the work item description, enforces that every entity regardless of their level of operation in this organization, would know the implicit value of their, explicitly and would work toward delivering the same.

And, that’s when we would come up with a JPMC <ReactOrAnythingElse>JS, JPMC OCR, Jbits (JPMC Quantum bits)  or JPMC pay, JKafka (JPMC’s Kafka version) or at least our own problem’s, our own solution. Furthermore, if a banking institution can do this much technological manufacturing, then that would be inevitably and automatically reflecting in the products and services we offer to our clients, and their responses/reactions most importantly. That cannot be contained. It would be contagious. We can imagine what this would look like.

• Keeping this in mind, and having thought through it from a few perspectives, I couldn’t just sit and wait for someone to act (this came from your words from our first in person meeting in our Chicago office. Build something of our own. We cannot keep relying on vendors all the time. Our own observability library would democratize the data and its services. Centralizes the troubleshooting space. That was powerful thinking.). Therefore, I came up with a format of work item description around the tasks that I was assigned, to begin with. It has to start somewhere. And just ruminating product driven development does not do anything actionable. It is the change of mindset that is needed and that wouldn’t happen without practicing it.
• If we thought through the item descriptions in the below format, provided to the resource acting on the item, it is evident that the resource is not just chopping beans for any meal but is for the Ukrainian civilians stranded in the war zones, homeless, longing for a meal would be fed straight from your hand vs chopping beans without knowing why. I think containing the responsibility of a resource would work well just like the micro-services architecture. But, containing their thought process would not. Would leave very little difference between the brains that can mindfully think and make better decisions always, instead of just making decisions like a bot would. Whatever AI we are trying to build (from the simplest: OCR to the most complex: molecular influences on genomic changes due to drugs), is to only get one more step closer to the way our brains and the nature already works. It would make a clear goal available in front of their eyes, all the time, that would drive every effort invested toward the goal. Impact aware development, we could call it?