Twitter
Google plus
Facebook
Vimeo
Pinterest

Fluid Edge Themes

Project Mindset Vs. Product Mindset

Project Mindset Vs. Product Mindset: Which has an Edge?

One of biggest obstacles an organization will face is elevate thinking and culture from a project level to product level. Both have the same end goal and both want a successful project on time and within budget and happy customers. However, having a product mindset always has an upper hand while delivering to their customers.

But first, let’s understand what project mindset and product mindset mean and its various roles.

The Project Mindset

There’s nothing wrong with a project in the first place. Realizing a series of tasks over a negotiated period of time is a perfect strategy for achieving a specific goal. A project can offer the necessary focus and stimulate collaboration and teamwork towards realizing ambitious and appealing goals.

Although the projects can be a great approach, they are often used incorrectly. Organizations are kickstarting loads of initiatives with temporary teams that concentrate on delivering on schedule, on budget and within reach. All those restrictions are laid down in stone. If the commitments reached earlier are fulfilled the project has declared a success.

Of course, deadlines, budget, and scope are important, but ultimately, it’s all about creating the best consumer experience for you. It is about maximizing the value delivered continuously. A project that meets all the deadlines will still result in a lousy product within budget and with the originally negotiated scope. Or to put it more bluntly: this will create a lousy product. This means you did not learn something during the project, or you did not respond to the lessons learned.

Project thinking is fairly pervasive. Many folks have spent a lot of their careers focusing on projects and project management, especially in software development. Large companies also have divisions of PMOs, focused exclusively on project management. It’s not surprising, because project management has been around for quite a long time. And as humans we prefer to think in terms of projects: things we have to do.

The focus of project thinking is delivery. This may be delivering different features or apps, or delivering something else. From aviation to building houses. And since delivery is the priority, the primary measurement is in timeline and schedule.

Project management focuses primarily on production, which is calculated by how accurately we were able to pre-estimate the timetable and then produce the required performance on that schedule. Success is generally described as taking the specs of something ahead of time, setting up a schedule along the way with milestones and then hitting those dates.

The Product Mindset

Product thinking takes a different approach, fundamentally. Product analysis is based on the result rather than concentrating on the production.

This is a significant shift from the mindset of project thinking. Rather of concentrating on deadlines and dates, we concentrate on the target that we want to accomplish or the work that needs to be done. Since we’re focusing on the result rather than the production, putting time limits on execution, at least up front, is much more difficult. This is mainly because we don’t actually know how we’ll reach the target up front.

This kind of thinking can be quite the change, particularly for people who have spent a lot of time working on projects and managing projects. Many people are uncomfortable with the uncertainty that they do not have structured timelines and schedules which they are able to monitor regularly.

Using such a product mentality means assessing performance with market metrics such as user growth and retention, and the per-feature sales or cost savings. It results in less waste, more imagination and more releases.

“Product thinking” is a way of doing business. This is a method of funding and coordinating the creation of software that varies greatly from the method the companies do it. Although generally applicable to digital-age enterprise IT, this way of working is especially suited to those who aim to drive business through a digital platform.

Product thinking is no longer limited to software-selling businesses. Tech platforms which stream content, e-tail, distribute mutual funds, find cabs, accommodation, flights, you name it. It is also catching on at more conventional, old-guard companies in the digital / product / engineering / IT divisions.

There are some combinations, less-than-ideal, with teams working in product-mode. Some places use a half way method of funding project-mode and organization of product-mode. Even the organization of product-mode aren’t always build+run. Or the cross-functional teams consist of people who report to different heads of functions.

An ideal product thinking team is motivated, result-oriented, collaborative, long-lived, cross-functional, ideate-build-run team that is willing and expected to solve challenges and boost market results, rather than delivering scope on time.

In product thinking, it’s not just the long-lived squad, it’s often long-lived partnership with a problem region. Product-style teams mostly work in pull-based mode of production with a focus on achieving flow and less emphasis on achieving predictability by estimation of story level and release plans.

The winner? It’s obviously product mindset and here are the reasons why

 Ability to Reorient Quickly

In project mode, it could be the case at a time that we have active projects involving order processing, payment and fulfillment but not catalogue due to priorities. So, if we were to receive unwanted, catalog-related feedback from either the customer or the company stakeholders, we would not have a team in place ready to respond on the feedback.

There’s a long-lived team (or teams) in product mode committed to each database, order management, etc., and always ready to act on new feedback. It would require only the decision of the product owner of the team and their business counterpart to redirect any ability of the team to act upon new knowledge. The ability to reorient a ready-made team quickly is the first component of better response.

 Reduced End-to-End Cycle Time

Cycle time is a standard measure of answerability. The time to reorient and the time to execute is included inside the overall cycle time. Now let’s look into the latter part.

Most DevOps enterprise initiatives don’t change the distinction between the organizations “change” and “run” at all. Typically, both organizations implement some new tooling, some installation, and some automation of technology, maybe with some “internet” thrown in for good measure. You can also consider advantages like more frequent, streamlined and efficient deployments.

However, the end-to-end cycle time of making a transition doesn’t transition much due to the continuity of the handoff from dev to centralized operations. Product-mode teams do not experience this handoff when deploying and operating what they are building. Thus, they will reach the maximum potential of implementing DevOps. Application level operations colocation with dev also facilitates faster end-to-end development and better communication between developers and reliability engineers on site.

Ability to Truly Iterate

Although the idea of iterative growth has been around for an although, iteration in practice in most situations goes just as far as a sprint showcase. Most Scrum teams are bound to sprint commitments based on scope and are required to achieve scope on schedule rather than problem solving. To solve a problem iteratively, teams need to be able to respond to the input from earlier iterations of the solution (usage analytics, user surveys, testimony from stakeholders). Product-mode teams, being stable and long-lived can choose to solve a problem in a truly iterative manner.

At Goavega, we focus on product-centric approach which helps us achieve quicker business outcomes, improved customer experiences, reduce friction within organization and add more flexibility. Moreover, we try to implement this ideology into our employees thus making them more responsive and functional. By doing so, we create an environment that strives on bringing quality service to our esteemed customers. Know more about our gamut of services here

Post a comment