Project Vs Product Thinking

Nurturing Development Team

Results are always measured against an accepted criteria. In recent times, there is a radical change — measuring outcome is gaining importance over the transactional output-based measurement. The major reason for this paradigm shift is because of “Product Thinking” mindset. ‘Product Thinking’ sounds like it is meant for teams in product development organisations and not for services-based organisation. Is that true? Surprisingly, it is NOT! It is for any team in any industry — be it in-house product development or outsourced project development. Instilling product thinking culture in any team creates a long-term, sustainable environment around the product, projects and the teams working on them.

Project Vs Product Thinking — is a common topic of discussion among business and technical leaders, but my stake in this topic is not just to present a comparison, but to unleash the potential of adopting a product thinking mindset to nurture development teams. Therefore, in this article, I am going to start with Project Thinking and its well-known problems, and conclude with Product Thinking and the positive vibes it creates with teams.

I love coding and it is easy for me to get this topic scoped with the development team!

Project Thinking Mindset

It is all about planning, estimation, delivery, and output. The idea here is that, the product owners and the technical leads assume that they know what they want and how to achieve them.

With those assumptions, a project plan with all milestones is laid down. The plan aims to be executed within the same organisation or outsourced and then the project gets kick-started for execution.When the execution is outsourced, we typically call the assignment as “project”. In this case, the project team is groomed with a delivery mindset. The service organisation’s team builds the project (product) and their client counterparts take it from there and run the product.

Typically, development team does not get much exposure to the product’s end-user problems, which are supposed to be solved. And there isn’t enough room for first-hand ideation or follow-up iteration. The workflow is similar to a traffic signalling system where the green signal is not owned by the development team instead the client’s technical team.

In some cases, UX Designers claim to have substantial information about users, their pain points and their expectations from a product if they have been shared/nurtured with all those. Even in that case, their knowledge hardly percolates to the developers/QA engineers when they commit to the project’s dynamics and time table.

So, what is considered a project’s success? Delivering the output as per the plan, which was estimated just before the first sprint of the project.

Caveat:

What if the assumptions were wrong? What if the solution fails to achieve the outcome?

This is one of the major problems many projects face and this is where politics wins, defeating the best ideas of any product. In reality, once everyone agrees on the plan — despite the best efforts to learn and adapt put forth by a very few — the major focus is merely on managing the milestones. Otherwise this can cause irrevocable problems for businesses if a project timeline is missed. I took a stab at this situation as shown below.

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

Case Study#1

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 Mindset

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.

The Equation:

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.

Case Study#2

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.

1. Step#1: Iterate — Discuss with Product Owners and, if possible, with the end-users.
2. Step#2: Build — Based on the outcomes of the ideation, build the MVP of the product.
3. Step#3: Run — Run the product and listen to the feedback of the product owners and end-users
4. Repeat Step#1 to Step#3 till the completion of the product development for all features.

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.

Conclusion:

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!

Photo Credit: Freepik.com