Project vs. Product Thinking: Nurturing Development Team

DZone 's Guide to

Project vs. Product Thinking: Nurturing Development Team

One of these types of project management is more effective in iterating with the end user in mind.

· Agile Zone ·
Free Resource


Results are always measured against accepted criteria. In recent times, there has been a radical change — measuring outcome is gaining importance over the transactional output-based measurement. The major reason for this paradigm shift is because of a “product thinking” mindset. "Product thinking" sounds like it is meant for teams in product development organizations and not for services-based organizations. 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 a product thinking culture in any team creates a long-term, sustainable environment around the product, projects and the teams working on them.

Project versus 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!

Development Team  = Architect  +/- Delivery Manager + Developers;

Project Thinking Mindset

A product thinking 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.

Image title

With those assumptions, a project plan with all milestones is laid down. The plan aims to be executed within the same organization 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 organization’s team builds the project (product) and their client counterparts take it from there and run the product.

Image titleTypically, the 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 signaling system where the green signal is not owned by the development team instead of 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 with 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.

Caveats with Product Thinking

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 should be 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.

public Result release(Mode mode, Date deadLine, Team team) {
   Result  result = null;
   if (mode == Mode.Project_Thinking )
    if (deadLine <= TODAY) {
      result = output; 
      System.out.println("Success! Sounds good!.");
   } else {
      result = output 
      System.out.println("Oops Failure, Something went wrong!");
   return result;

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

Case Study #1

I was asked to revamp the entire architecture of a product from a healthcare innovation startup company when I was associated with Imaginea. The healthcare 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.

I was able to influence the client’s decision-making authorities by showcasing our technical capabilities in building microservices from scratch. After that, it was the time for scoping, with all the assumptions outlined, I estimated the deliverables and bagged the deal. Or, should I say, the "project."

Weekly sprints and demos were on with tight schedules with me and my development team. 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 microservices 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 both 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 supreme quality and user experience.

Image title

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's coffee, 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 ambiance, 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!

public Result release(Mode mode) {
   Result  result = null;
   if (mode == Mode.Product_Thinking )
    result = output + (experience + learning & other benefits);
    System.out.println("Sounds good!.");
   return result;

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. I impressed the prospect with our technical strength, which was quite explicit from my 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 microservices. That being said, the mindset of the client stakeholders did not incline towards effort and estimation, but instead on the outcomes! Starting from day one, the journey was well-nurtured by the technical and business owners of the product as depicted.

Image title

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.

Image title

  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 my 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 emphasized 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!

Originally published in Medium.

product deisgn, product development, product development lifecycle, product development strategy, product thinking, project management

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}