When it comes to software development, the traditional approach has been to treat it like a project with tasks that are distributed among different teams and then integrated to create the final product. Everyone is assigned their bit of the work, and the product is delivered as a team.
The problem with this approach is that it is task-oriented. Developers are asked to concern themselves with their checklist of to-dos, their goal being to focus on finishing them as soon as possible. On the surface, this seems like an excellent way to move along development swiftly; in actuality, it slows down the project and prevents developers from gaining a big-picture view of the product.
When organizations have to compete to get the right product out at accelerated speeds, pursuing a traditional project-driven approach won’t cut it. To deliver a product that users will love, at a competitive time-to-market requires a product-centric approach.
What exactly is a product-centric approach?
Consider a scenario where you have to develop a software application. In a traditional approach, the organization will focus on the project and project delivery, dividing software development into different phases, where each phase is designed to perform specific activities. The stages are: gathering requirements, designing (planning the programming language, and high-level technical details), building (coding the software), testing, deployment, and maintenance.
Success metrics are aligned to the project, such as ‘delivering within scope’ or ‘project within budget’. Despite these metrics, the project takes a long time to be delivered, and when it is delivered quickly, it is not up to the mark.
The journey to product delivery is inherently laborious. In a large organization, development has to jump through demand management and governance hoops, which can take many months. The work begins only after the company has compared the initiative to other opportunities and deemed it critical. Organizations are increasingly abandoning conventional funding mechanisms in favor of allocating budget at the division level and deferring governance to the line of business.
Purely from the design and delivery perspective, organizations can save time further by focusing on the product’s core functionality first and launch it quickly for user, while rolling out features slowly down the line. In other words, the product team can deliver incremental value more often.
A product-centric model puts the product at the heart of delivery, and worries about other project aspects such as documentation or future functionality later. Efforts are directed at putting out a functional project at the earliest, satisfying user demand early while laying the ground for early feedback that can be incorporated into feature-development work.
Product centricity eliminates silos
A project approach to software development invariably creates silos. Imagine an app development environment where developers are siloed off from one another and focusing on their goals rather than gaining a top-level view of the product. In such an atmosphere of limited communication between people who are working on the same product, there is a high chance that long-term goals will move to the sidelines, and the developer teams will only feel motivated to finish their tasks.
Beyond potentially affecting the quality of the product and its future possibilities, silos can also impact developers’ morale. Lack of transparency can have negative consequences, preventing different teams from developing mutual trust and create anxiety around reporting issues out of fear of not being able to do their bit of the project properly. In the absence of an open, sharing system, the risk of misinformation and delayed workflows can increase.
80% of organizations plan to adopt a product-centric application delivery method by 2022
The above statistic from Gartner indicates that product centricity is gaining steam in the software development realm. Given that clients, partners, and other third-parties use an increasing number of applications developed by organizations, product-centricity, and a growing customer focus seamlessly go hand in hand.
The survey found that organizations have decided to go the product-centric route to deliver more quickly and boost their speed-to-market. Another driver is the move to a transformative business model in an age of digitalization; traditional project methodologies are ill-suited to the volatilities and uncertainties that have become part and parcel of the business landscape.
As indicated previously, product centricity will call for a shift from project-based funding to product funding. This change and the potential culture clash that it can create between IT and business are the top concerns of organizations committed to a product-centric development model. Additionally, the survey revealed that many organizations had already appointed a product manager.
Agile development is a key pre-cursor
The Agile approach to project development involves creating software incrementally, wherein organizations offer users new releases, versions, or software created from brief periods of work known as ‘sprints’. The Agile manifesto states four core values for development:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Agile development and customer satisfaction: In a Waterfall development approach, the customer gets to see the product only at the end of the project. In an Agile approach, the customer has early and frequent opportunities to look at the product and may propose changes. If there are errors in a waterfall approach, they are identified at a later testing stage and may require developers to move back a few steps to rectify the issue. An agile approach allows the chance to correct errors during the course of the development.
User acceptance – a testing performed to ensure that the software can handle the required tasks in real-world situations, to agreed-upon specifications, is done at the end of the sprint. All these factors add up to a more transparent and involved customer experience, ultimately satisfying them more than what traditional development methods can manage.
Agile development and developer transparency: As the development process is iterative, planning is limited, and project execution times are between two to four weeks; developers feel less bogged down and pressurized. In a waterfall approach, each phase of development is more significant than the iteration and ends with a detailed description of the subsequent step.
Agile development requires teams to communicate closely and analyze requirements and planning jointly. Testers and developers work together. The emphasis is on collaborative delivery rather than the mindset of ‘doing our share of the work’. Rather than fixate about personal or team ownership, people can focus solely on meeting sprints and delivering minimum viable products as quickly as possible.
Additionally, an agile development approach makes it fine to accommodate changing requirements and allows teams to reflect at regular intervals on how to improve effectiveness, and adjusting behaviors accordingly. This mindset motivates teams to pursue excellence continually and equips organizations to respond to new market trends.
Framing the product as a living thing
A product-centric approach to software development envisions the product as a living, breathing thing that requires care and can advance rather than merely having a start and end date. The focus then moves from only delivering the product on-time and on-budget, and shifts to providing the product quickly even if it is not yet complete, and performing its core functionalities effectively.
When the metrics for success change, the attitude towards development follows suit, those working on the project can keep the focus on creating a great MVP. Then shift attention to rolling out features that users will appreciate, all the while having the breathing space to accommodate changes without having to go back to the drawing board. Incentives and motivations of product development are better-aligned to the intrinsic human motivation of designing something of real value to users.
Traditional project management principles of product delivery still matter
A transition to product-centric software development and delivery does not automatically mean abandoning tried-and-tested project management principles. The fundamental aspects of ensuring business alignment, getting executive sponsorship, and handling change management are still essential to successful product development and delivery.
The product needs to provide a definite value to users, and there must be a clear justification for developing the product. Everyone involved must be clear about the product’s goals and be aware of the expected outcome. The success criteria – what defines success even if the product is not complete – must be crystallized. For this, teams should have completed change management steps and communicated the product’s capabilities before rolling it out. They should proactively collect user feedback, assess user adoption, and leverage these insights to make improvements after the product’s launch.
The time to make the switch to product-centric development has arrived
Organizations that adopt product-centric development stand to gain from better speed to market, closer interactions with customers, and greater transparency and collaboration between development teams. In particular, companies building a new app or their first app can significantly benefit from the opportunity to launch a minimum viable product and create consumer interest in their brand without having to wait several months or even years. In a dynamic business environment, entrenched organizations will also do well to utilize product centricity to pivot to new trends and seize emerging opportunities to gain a competitive advantage. Want to know more about this topic? Contact us; we would be more than happy to exchange with you about agility and product-centric approach!
|FUNDING||Annual||Continuous, with more frequent (e.g. every 3 months) checkpoints on shifts in funding and resources|
|TIMELINE||Discrete with formal start and end dates||Continuous, assumed to be ongoing; no firm end dates, although product can be retired|
|TEAMING||Matrixed – orchestration across departmental and technical domains, but with functional teams owning the resources||Multidisciplinary- much of the team working full time on the product, breaking down the silos of functional specialization|
|METRICS||On-time/budget, although IT organizations that are more mature may measure projects based on business outcomes||Customer satisfaction, profit, market share
source: Gartner (May 2017)