What are the benefits of using a product approach in software development and how is this different from typical IT projects?
More and more modern IT companies are leaving behind old ways of managing their software business and turning themselves into product oriented organisations. Some of them are restructuring and replacing all project management related positions with Product Managers or Product Owners.
So what is the Product Mindset and what are the reasons behind its growing popularity?
Let’s begin with explaining how those two differ:
According to the definition, A Project is a temporary endeavour undertaken to create a unique product, service or result. A Product, on the other hand, is anything that can be offered to a market to satisfy the desire or need of a customer.
As you can see, those definitions are more complementary than contradictory. So, what is the point of pitting them against each other?
The difference between the two approaches is subtle, yet fundamental. The product approach emphasises the commitment to focus on the customers and their business objectives. Another important aspect is the temporariness that is built in to projects which often drives short-sighted, tactical decisions. In some cases, this will still be successful, however building a product is more like a marathon, than a sprint and prioritising quick wins will likely backfire on you sooner or later. It may lead to building technical debt resulting in quality issues, difficulties with scaling, bad user experience, etc.
In the product approach, the typical project management success criteria are often neglected. We tend to care less about delivering fully on the scope that we initially defined. The delivery schedule also isn’t carved in stone as our primary goal is to satisfy customer’s needs.
Let’s look at how the above affects specific stages of software development.
As Peter Drucker once said:
There is nothing quite so useless, as doing with great efficiency, something that should not be done at all.
This thought is also reflected in one of the Agile Principles:
Simplicity — the art of maximising the amount of work not done — is essential.
Sounds obvious, however experience shows that it is difficult to answer the question: Which features will encourage a user to choose our product over others available on the market? Or even more importantly: Which features will make a user so happy with the product that she will recommend it to a friend?
With a product mindset, you should spend much more time figuring out: “Who is the customer?” and “What is the purpose of our product?”, before diving straight in to designing features or creating the system’s architecture. Two artefacts that will help you get closer to answering those questions are: product vision and persona. A well described vision is a glimpse into the future to describe the positive impact the product should make. It will also help to define what is the expected user experience when interacting with the product. A Persona is an imaginary user of our system that will help us to better target the features of the product to a specific audience.
Another powerful tool worth mentioning is the customer journey. It combines the product vision, personas and user interactions with the system and visualises it all on a single timeline. This helps to identify and plan features which can create positive emotions and experiences at each stage of interaction with the product. The Customer Journey map can also help you with setting priorities when creating the features roadmap. It can also help to align the whole product development team when it comes to contextualising customer needs and business priorities.
When you have your product vision statement defined and the strategy to conquer the market is in place, then the time has come to verify your assumptions regarding the product.
Modern prototyping tools (like UXPin, InVision) allow fully functional, interactive user interfaces to be created in no time. This enables you to verify your hypothesis regarding user needs with test groups. With a few iterations, you can quickly see if the features and/or look & feel of the product meets your customers expectations. The product can be tweaked until the test group is satisfied and you can then move on to the construction phase. This prevents wasting time on building features that no one needs or likes.
Prototyping also eases communication between engineering and the business. You are able to engage customer representatives early in the development stage and invite them to co-create the product with you. It is much easier to work with a tangible prototype than written requirements. Getting feedback is quicker and the suggestions tend to be of higher quality.
Prototyping also significantly enhances creativity as this way of working is more inclusive and we can engage wider groups of people with different backgrounds and skills. They can provide their opinions after interacting with the product without having technical or domain knowledge or requirement management experience. Listening to these suggestions and pain points can save us enormous amount of time compared with having to do a redesign in a later phase. In addition, you may get completely new ideas for functions and features that you might not have thought of otherwise.
In the product focused organisations , Feature Driven Delivery (FDD), is often used — building and releasing functionality incrementally. The product is decomposed into items that are relevant from the customer perspective, prioritising them based on business value. It is important that the product backlog is populated with items that provide a description of the system behaviour, rather than purely technical tasks — which will ensure we focus on business value first. Any Prototypes created in earlier phases can help describe the desired functionality better than words alone.
In the product focused organisations , Feature Driven Delivery (FDD), is often used — building and releasing functionality incrementally. The product is decomposed into items that are relevant from the customer perspective, prioritising them based on business value. It is important that the product backlog is populated with items that provide a description of the system behavior, rather than purely technical tasks — which will ensure we focus on business value first. Any Prototypes created in earlier phases can help describe the desired functionality better than words alone.
To make Feature Driven Delivery work, it is necessary to ensure that your organisation is prepared to work in this model — you need to ensure high quality (automated testing) and efficiency of software development process (CI/CD). Transforming an organisation into a product-oriented one, often requires changes to its structure. You need to build long-lasting, cross-functional teams capable of delivering product features that will often need to slice through all the layers of your software stack and touch multiple business domains. Doing this is very difficult to achieve with just a project approach due to its temporal trait.
When you decide to go the FDD way, first and foremost, the benefit will be the ability to get to market faster. The price you may pay for speed won’t be quality but it may be the feature scope of the product. However, this will be balanced out by reducing waste related to building unnecessary features in the early stages of product discovery. Gathering feedback early and pushing for high development process efficiency enables you to understand and respond to user needs faster than your competition.
The Product approach definitely won’t replace project management entirely in software development. In scenarios where budget and schedule are fundamentally fixed, project managers need not worry about their future!
On the other hand, if your goal is creating products that will delight your customers and win market share, then you should consider focusing your organisation on the product and deepen your tools for discovering where the customer value is.
Note that the product approach isn’t only for newly designed, innovative products — you can get great results with these techniques when refreshing existing applications or adding new features on existing systems. It can help you to select the most important features and update them one-by-one, in priority order, with less resources and without the need to wait for the whole scope to be completed.