Why do you want to instill product thinking in your technology team?

People working on software applications believe that they are only on a temporary project. When it’s done, they can move on to other projects. The software application is seldom treated as a “product” however it stays alive for many years after the project is completed. Here I attempt to demystify some of the key facets of product thinking, product management and product engineering. I leveraged excerpts of my discussions with several product managers, agile practitioners, digital product engineering leaders and my learning from several books, blog posts, and websites to pen this article.

The Project Mindset

There is nothing wrong with a project. It is a great approach to execute a set of activities over an agreed period of time to deliver expected output. A project can offer the necessary focus and stimulate collaboration and teamwork towards realizing ambitious and appealing goals.?However the problem is with how project teams and the project for that matter is managed, measured, and judged. Temporary project teams are focused on delivering on time, under budget and within scope. These triple constraints (scope, cost and schedule) are set in stone and when these constraints are met, the project is declared success. Since short lived project teams are judged on conformance to the schedule, they have ample incentives to take shortcuts, avoid refactoring, and compromise architectural stability/integrity, vertical & horizontal scalability of the software application etc. with the understanding that the next project team or operations team will fix issues down the line. So the burden of technical debt, sub-optimal design choices are passed on to the next group and a lack of ownership of the software product is demonstrated.

Project based organizations typically have a separate “Run”, “Support”, or "Maintenance" team that fixes defects and makes small enhancements in between projects. The problem with this is the development team doesn't get to learn from the production problems they created. Also, project based organizations augment development teams with temporary external resources who leave at the end of the project taking most of the knowledge and/or subject matter expertise with them leaving the “Run”, “Support”, or "Maintenance" team to figure out how things work!

Views and opinions expressed in this article are my own?and do not?reflect?official policy or position of my employer and/or any other organization(s) I was/am associated with.        

The Product Mindset

“A Product Mindset is a set of beliefs, skills, qualities and techniques that successful product makers possess that allows them to learn, push through challenges and setbacks, master new skills and tap into the success of their peers and others”. Product mindset focuses on outcomes not outputs; measured by continuous value the product is adding; qualified by adaptability, agility and durability of team.

A product-centric approach usually goes hand in hand with adopting agile software development mindset. In an agile team using?Kanban or Scrum, for example, there is no “project” at all—there is only a continuous stream of value-delivering work, prioritized by someone (known as product manager, discussed later) who keeps a finger on the pulse of the customer. Product-centered teams are autonomous, cross functional, self-organizing and purpose driven; they can create business value rapidly?and quickly stop and/or pivot when pursuing a dead end. Project-centered teams continue to follow the signed-off plan regardless of how disappointing they know the outcome will be.

Predictability and Adaptability – Can they coexist?

Project mindset promotes predictability over adaptability. While on the surface it may look like software development is predictable; in reality no significant development activity is repetitive and predictable. Project management processes were developed based on step-by-step, predictable manufacturing models the United States military used during World War II. Focus on predictability was complemented by elaborate long-term planning, comprehensive requirements document, begin-with-the-end-in-mind-and-make-assumptions kind of design, Gantt charts, work breakdown structure and so forth.

Traditional project management principles focuses on risk avoidance and hence comprehensive documentation, formal sign-off by long list of stakeholder, multiple reviews of work output, shared ownership/accountability (or lack thereof) are in the fabric of project centric organizations. A risk-averse organization may be highly predicable but that is at the cost of experimentation and innovation. No risks, no experiments equate to no learning and if software can be developed in no-experiment environment chances are that commercial of the shelf software are out there that fit the bill well. In complex, unknown, unpredictable world of product engineering faster test and learn, inspection and adaptation are must haves.

Organizations use a suite of products and a host of services; some of those are built in-house, some are purchased and some are subscribed to. Let us look at how we can separate services from products so required focus/resources can be dedicated to the right areas.

Diffusion of Products & Services

Basic differences between products and services are easy to spot. Products are tangible or intangible things that are already built and can be used or consumed now or later, while services are intangible and cannot be produced in advance. Of course, many purchases consist of a mix of products and services. Restaurants are roughly balanced between the products and services whereas airline flights are mostly services if we consider refreshments as products. So pure products and pure services are extreme end points on a continuum of possibilities.

A product needs to be relevant; the users must have an immediate use for it. Each product has a useful life after which it needs replacement, and a life cycle after which it has to be re-invented. A product can be revamped, re-launched or extended to make it more relevant to keep pace with the changing phase of technology and competitive landscape. Services must be continuously improved following a plan-do-check-act cycle more frequently to stay relevant.

Type of Products

For simplicity and ease of understanding I like to divide different products an organization use into two categories. The first category consists of the products that are customer/associate facing; they are expected to change frequently to deliver seamless friction free customer experience and to address changes in customer preference. This category of products should ideally be built using same or similar tech stack to leverage fungible resources following a value driven agile delivery model and on-demand scalable infrastructure to support speed of innovation and test & learn approach. This group of products is known as “Front of the house systems” or “Field Systems” or “Front end systems” or “Customer/Associate facing systems” depending on the industry. Examples of such products are Point of commerce, Websites, Mobile Apps, Order management, Customer service suite etc.

The other category consists of products that focus on facilitating core business processes such as finance, accounting, merchandising, logistics, inventory etc. Some of these are purchased as package or SaaS. These are, in general, expected to change less frequently. These products are equally important, if not more, and organization expects that these are always up and running with greater stability. Changes to some of these products may mean a large scale upgrade or replacement of an existing product. Customer/associate facing products typically integrate with one or more of these products. This group of products is called “Back of the house systems” or “Corporate Systems” or “Back end systems” or “Enterprise systems” depending on the industry. Examples of such products are ERP, HR, Finance, Marketing, Inventory systems etc.

Why Identifying Products and Services are critical for an organization?

Correctly identifying products and services in an organization can help avoid problems related to resource allocation, organization wide prioritization, and team structure. Identifying products is not easy. Often there are disagreements over product type or if something is a product. As product features are added, features themselves often spawn into products that warrant review of the existing organization structure and/or additional resources. The leaders should be asking (a) of the existing products which ones are worth growing, which ones should be maintained and which ones should be phased out? (b) What type of products is worth invested in, what should be built, what should be bought? (c) What are key customer experiences that will drive value, and loyalty; and which products support that? (d) How can we expedite the test and learn cycle and collect data to drive future product iterations and/or innovation?

The role of Product Owner

The Product Owner (PO) should virtually “own” the product. Being a member of agile product development team, PO is responsible for driving product success. PO is trusted and empowered individual who represents the customer; develops product vision, strategy, and direction; provides product expertise; decides what is included and not included in the product. Job titles associated with product owner role vary from company to company, some associate “Product Manager” job title with the PO role.

Having transformed IT teams to adopt product mindset in manufacturing and retail industries, I can tell you that it is hard for organizations to understand the role of the product owner to start with. The role is perceived as “new title for business analyst in agile team”. This unique role operates at the intersection of product strategy (understanding and defining an opportunity, competitive landscape, legal, economic and political eco-system), product ownership (owning product roadmap, success/failure of the product, driving improvements on the product, making hard decisions on investment/priorities on product components/features etc.), product management (developing, refining, and prioritizing product backlog based on increase in business value and reduction of business risk and aligning internal/external customers etc.) and product marketing (define and execute go-to-market strategies).

Product managers can come from any part of the organization, from business or technology arms. Customer focus, collaboration, self-confidence, communications, presentation skills, managing up, ability to get stake holder buy in on an idea and/or investment, passion for products, passion for data/analytics, and time management are key skills to look for in a product owner.

How do we go about building a product?

Great products never happen by accident, but by design. Product manager has two key responsibilities in this respect: assessing the opportunity, and defining the product to be built partnering with engineering team. The product manager collaborates with user experience (UX) designer and product engineering team to keep everyone’s focus on the “minimal viable product” (MVP) - the smallest possible product with just enough features to satisfy early customers while providing optimal brand experience.

Building of product starts with an “opportunity assessment”, which provides an efficient way to quickly assess a product opportunity target market and estimated ROI. Opportunity assessment focuses on the user or business problem (the “what” NOT the “how”) that the integrated product team is trying to solve and not the particular solution they have in mind.

Customers don’t know what they want until after they see it. They also don’t know what is possible with new technologies. That does not mean product managers don’t need to talk to the customers. While more time with customers does not guarantee better understanding of customer needs, little to no time with customer almost guarantees lack of real understanding of customer needs. Instead of taking an approach of asking customer “what you want?”, the product manager should test ideas with customers to see which ideas actually work that can be scaled! More than 2/3rd of new product ideas typically fail because they are either very complicated or expensive to build. And that is okay, part of innovation is experimentation and experimentation will have failures and learning opportunities which make the team stronger and smarter.

Here are a few key fundamental concepts on product management and product engineering.

Dedicated Team

Many organizations make mistake thinking of product as project. For example, when an organization wants to build a product, let’s say a website or a mobile app, they usually partner with an agency (because they don’t have their own people with the right skills) for 4-6 months and get it done, and then the folks from agency leave to do something else. This is not how we get to a great product; a great product is built by a well-funded, durable team that operates with product mindset.?The dedicated team is a collocated cross functional team (user experience, design, creative, product management and engineering). This team should be durable for a relatively long period of time and dedicated to a domain or a bigger scope of responsibility and is charged with responsibilities of adding all new features, all redesigns, all bug fixes, all performance improvements, and all optimizations for that area – more like a startup within the organization.

Manage By Objectives

Instead of a list of features to be built, providing a set of outcome (for example KPIs the team will measured against such as a different conversion rate, a different revenue goal or a different system performance goal) to a product team drives more sense of ownership, and commitment. Stakeholder will still provide different ideas, but the job of the team will be to pick up the most promising ideas and then build them.

Importance of Design

Most people think of design as look & feel, and some think of it just in terms of usability. Design does include look & feel and usability but there is so much more to it. Design is “how it all works”, design is something that is not to be bolted on later, and it is to be there from the ideation phase. For most products, coming up with the best experience is usually harder than coming up with technology solution.

True Collaboration

Single biggest source of innovation on a product typically comes from the engineers, especially lead engineer(s), not from the product manager or the experience designer. Because the engineers understand the technology best and know what is possible with it. Product management, product engineering and UX team working in lock step keeping the eyes on the prize results in great product.

Reality Check & Pivot

Learning to differentiate between vision and illusion is critical in product management. Knowing when to stop pursuing an idea, or to relax the original vision a little, or to change the problem statement, or to change the business model to build something exciting is a hard earned skill. Psychological factors such sunk cost, team’s emotional attachment with what is being built deters many product teams to look beyond the original product vision. However highly successful product teams are those that perform reality check frequently and genuinely consider pivot opportunities. Many successful brands of today, such as Groupon, Facebook, Youtube, Twitter, Instagram, and Paypal to name a few, were born out of pivot.

Changing from a traditional top-down, command-and-control, project-centered corporate culture to a lean, agile, product-focused culture is difficult, but the rewards are tremendous. A once-upon-a-time online bookstore, a pizza company, a video streaming company have consciously chosen the path of product centric culture and have been immensely successful; and so can you.

Views and opinions expressed in this article are my own?and do not?reflect?official policy or position of my employer and/or any other organization(s) I was/am associated with.