How the Right Product Mindset Can Propel Business Outcomes
Product Mindset Principles: What engineering teams must do and should do.
Join the DZone community and get the full member experience.Join For Free
Today’s engineering teams often use agile methods to guide software development and adhere to the principles outlined within the Manifesto for Software Development. These principles, which were created as an alternative to documentation driven, heavyweight software development, represent the dominant force that led to the ‘continuous delivery in software’ approach that is prevalent today.
At Talentica, we have worked alongside more than 150 software development teams, including early-stage companies, in the last two decades. This experience has underscored the need for a separate set of principles to help CEOs, CTOs, Engineering VPs, and other technology leaders to align their engineering teams with strategic outcomes beyond just product delivery.
To this end, we developed the ‘Product Mindset Principles’ that are critical for startups and growth-stage companies when the product can make or break a company. But companies of all sizes and stages can impact their businesses by following these principles.
The principles consist of two related categories: a) things engineering teams must do and b) things they should do. The must-dos are essential to successful product delivery; the should dos will impact the business beyond product delivery. Here’s how the principles work together:
Product Mindset Principles
Value Manage Scope Creep Over First Time Right
Developers must correctly fulfill user story requirements the first time they’re given. The First Time Right principle means Product Owners find nothing wrong, and it can be moved to production after resolving the minor discrepancies, if any. Typically in startups, Product Owners define high-level user stories with links to wireframes/detailed visual designs. It is challenging for startups to provide detailed acceptance criteria for every user story in a written form as their main focus is always on achieving the next business milestone within 18 to 24 months. Developers and QA engineers with a firm grasp over the product should know what to look for and ask relevant questions to uncover complex/edge scenarios to ensure they can deliver First Time Right.
Simultaneously, developers should strive to manage scope creep while getting stories right the first time. Scope creep is the expansion of a user story after the Sprint begins; it usually happens when the requirements change after they are defined. For example, scope creep occurs if the product owner looks at a user story that is “Ready for Review,” and before releasing to end-user feedback, they change what’s on it. Scope creep wastes time, increases costs, and compromises First Time Right.
Managing scope creep requires teams to ask the right questions upfront to ensure that the user story does not fall apart during development due to scenarios not thought through or because of technical constraints. The objective is to get into production without spending multiple Sprints on one story. Teams can greatly improve Cycle Time when they align with the product and help the Product Owner manage scope creep.
Value Feature Adoption Over Commit and Deliver
Commit and Deliver comes from a Scrum principle about teams committing to stories in a Sprint and delivering them without changing their quality and scope. It’s a commitment to customers about the work developers will do. For example, if engineering teams commit to completing three customer stories, they must deliver them and get them right the first time.
Engineering teams should uphold this principle while increasing user adoption of features, which significantly helps product owners. For instance, if there was a story for building a resume parser as part of recruitment software, the developer's job wouldn't end once it was in production. Building a feature and moving it to production is just the first step. They should assist the product manager by determining how much the feature is used, how, by whom, and other metrics that impact future iterations, making the feature and overall product better. It is the Product Owners’ responsibility to find these things out, but developers can enable them with pre-built analytics for these metrics with a dashboard. They can work closely with developers to identify the right events and information to be captured to determine the adoption and ROI of features in the long run.
Value Innovation Over Problem Solving
Developer teams must solve technical challenges arising from products, features, and iterations. Solving technical challenges requires solid technical expertise, creativity, persistence, and the ability to dig deep into code written by other developers. Problem-solving is distinct from good, flexible, and extensible design. It deals with finding solutions to your unique problems because of the technology stack with which you are dealing. For instance, your Java-based system deployed on Kubernetes has reliability issues. The developer needs to have a solid understanding of JVM as well Kubernetes and then do profiling, dig deep, and provide a unique solution. Products are of no value if they don’t perform well; the goal is to increase their operational efficiency for customers in production.
But beyond problem-solving, teams should also anticipate, look for, and identify opportunities to innovate. However, innovation does not have to be top-down or the result of a huge breakthrough. Small, incremental innovation coming from different strata within the organization can ensure better outcomes. Teams can adopt a process where they identify technical process and product-related gaps at regular intervals and prioritize features that will plug these gaps. This will make innovation a way of life rather than a one-time activity.
Value Architectural Longevity Over Short Term Agility
Engineers must design with short term agility to get new features in the market as quickly as possible. Emergent Design is a helpful technique that supports short term agility for changing software as they back the requirements for feature changes.
Often, engineering teams are focused on features and agility, and with poor or absent technical leadership, they don’t manage their technical debt, enabling architectural violations to occur. The Architecture Longevity principle ensures the preservation of architecture’s integrity, so it doesn’t become too complex to add or change features. Besides, technology leaders need to ensure that they put the right governance in place to ensure that the application does not turn into a Big Ball of Mud that demands an entire software rewrite.
Product Mindset Matters
By upholding these principles, CTOs, Engineering VPs, and other technology leaders can maximize engineering teams’ effectiveness and efficiency to increase customer satisfaction scores, decrease time to market, and create a market-fit product, ultimately propelling the business forward.
Opinions expressed by DZone contributors are their own.