Nurture development teams with product based approach 

Weird, isn’t it? But that’s the ugly truth. I wish to illustrate the above using a case study.

We were asked to revamp the entire architecture of a product from a healthcare innovation startup company. The company was delivering educational media content to patients and physicians at the moment of care. Since it was found to have difficulties in scaling, the company planned to invest in breaking up its RoR based monolithic product into Java micro-services- just another typical investment for bringing up architectural changes to a product nowadays.

We were able to influence the client’s decision making authorities by showcasing our technical capabilities in building microservices from scratch. Post that, it was the time for scoping, with all the assumptions outlined, we estimated the deliverables and bagged the deal, Or, should I say “project”? 🙂

Weekly sprints and demos were on with tight schedules. The focus was partially on the architectural and design discussions and mostly on the agreed delivery timeline.

There were a few changes in the client’s technical and product contact points. Then the focus got completely shifted from building the product to constructing the project. The changes did not slow down the velocity of project delivery though. The recommended micro-services architecture, design and the implementation were all delivered as planned. But the change in the mindset made the deliverables more or less just another output. In this case, the team was driven to deliver the output but not empowered with information around the end-user’s expectations.

This is one of the typical examples of project thinking where the focus was on output / time though it was a product development from scratch.

Product Thinking is all about the outcome!. Output and outcome, they all sound the same, don’t they? Actually not. When it comes to product thinking, we don’t essentially focus on timelines and dates, but on delivering the product with a supreme quality and user experience.

Not so clear? Let us take a typical example of coffee, one of the most consumed beverages worldwide.

The output of any coffee shop is delivering a well-brewed beverage that people enjoy. Regardless of which coffee shop you choose, the outputs are almost the same

Have you wondered why 80% people across the planet choose Starbucks for a great coffee drinking experience? Yes, we may simply say we like Starbucks! But let us add some rationale to our choice. So what is our selection criteria? It is nothing but the outcome. What we get from Starbucks either meets or exceeds our expectations, and that is why we choose one of its products.

So we now know the difference between output and outcome, and we say product thinking is all about outcome. So far so good, but do we not get an output in product thinking? To answer this question, let us go back to the same analogy of the coffee shop. So, in any Starbucks outlet, we enjoy the ambience, the aroma, and many more things along with the hot coffee in a well packaged cup. So the output, the coffee, is delivered but the journey of the delivery is well appreciated by the end user as well. That’s where the difference lies. The entire package is the outcome. I am sure, we now know the equation!

Let us dive in with a case study, which will better explain what product thinking is all about.

One of our prospects came up with an architecture revamp requirement as their product was unable to horizontally scale well for the current market demands. The product serves the US enterprises as an automated platform for channel marketing. We impressed the prospect with our technical strength, which was quite explicit from our architectural proposal.

During the initial phase, they shared Lightweight Business Cases with capabilities and enablers, which detailed the expectation in breaking up the PHP based monolithic application into Java micro-services. That being said, the mindset of the client stakeholders did not incline towards effort and estimation, instead on the outcomes! Starting from day one, the journey was well nurtured by the technical and business owners of the product as depicted.

The processes marked green iterate based on the feedback received from the end users of the product. Let us get back to the traffic signal example and acknowledge the differences.

There were remarkable changes in the way the whole development team approached this problem

• The features were developed keeping the end-users in mind by all the participating team members (Development or UX or QA), Each team member could clearly articulate the end-user needs, which made it outcome-oriented
• There were no upfront estimation and dates in place. So, the team is prepared for solving problems rather than delivering the implementation on a mentioned date.
• The team had a good sustaining process with the iteration model in place. It focused on the outcomes and emphasised less on fulfilling the story level estimation and plans.

So, do we encourage a product based approach? When a product development from scratch is planned either in-house or outsourced, engage the team in the complete journey of product development. This helps in making the team talk in terms that make more sense to business and think in terms of business value and not tasks. This results in having a greater impact on decision making rather than going for a typical project delivery. This change ultimately gives the product the quality of life it deserves! It is inspired from the mantra of Agile methodology — Fail Fast, Learn, and Add Value!!

Let us nurture the development team as we nurture the product!