Introduction

A challenging new year is ahead of you. New projects, new products, further achieved goals. What should you pay attention to make software development the best investment? In this publication, I discuss trends that work well in my daily work and thanks to which my clients achieve above-average results. These trends are also very much visible in the recently published product development books, such as the second version of the book Inspired:

How to Create Tech Products Customers Love, who is one of the partners in the Silicon Valley Product Group, or the book

Project to Product

They indicate that the market is won by those who have well understood the concepts created around the agile movement and can quickly adapt to the real needs of customers and dynamically respond to changes, and think long-term through the prism of product construction. This is done from the very beginning, when, together with our clients, we verify whether our hypotheses regarding the problems to be solved by the created product are true and whether our target group confirms them. The same applies to the solution. The sooner you discover a solution that solves user problems, the better for your business.

Is the question? How does this way of thinking to squeeze into the bloodstream of people involved in your project? How to make developers stop being focused on providing more functionalities? That they would be required, that they would like to take responsibility for long-term product development?

The most important thing is to change the way you think. We erase the word project from our dictionary and replace it with the word product. This is the most important thing.

Why:

• projects have no vision

• projects have no mission

• projects have no strategy

• the developer does not connect emotionally with the project

• the project does not speak of business goals

• functionalities are provided in the design

The sooner you start thinking about your application or solution as a product, the sooner you focus on making all the people involved bring more real value.

Instead of building more functionalities, people from your team will start supporting the achievement of business goals. What is very interesting, supporting the implementation of business goals also applies to technical persons.

Something that just a few years ago seemed abstract. Just as the business did not understand all slogans such as scrum, agile, sprint, or flashback, technical people were not interested in business goals. This concept was reserved only for management. We see how much it begins to change and how better the world of technology understands the business world, and vice versa, the money invested in product development will pay off faster. This is not a hypothesis – these are the facts that you see in many successful initiatives. Many of them, such as Netflix, Airbnb, LinkedIn, or Workday, mention and describe in their book Inspired: How to create tech products customers Love Marty Cagan.

So once again – we remove the word project and replace it with the word product. What changes in perception and action after such a change? Here are the most important trends that we observe in the daily practice of building products by Leaware.com.

 

Mission and vision

 

Project Approach

In a design approach, mission and vision are very often not defined. It often seems that the time will come. This is a big mistake that can take revenge very quickly – e.g., how to set business goals for a project if we do not know where our product should be in a few years (vision) and we do not know why we create it (mission) – our “why”.

Product approach

Defining the vision and mission is the starting point – whether it is a product for internal customers, for the consumer market, or B2B. The basis is the vision – where we want the product to be found at a specific time and the mission – why the product was created. He brilliantly described the issue of “why” Simon Sinek in the book “Start with Why”

I know from experience in the development of various products that the perception and perspective of working on a product change significantly, in which we understand what we want to achieve and why we build this product. Very often, it turns out that during talks about the project with sponsors, they have a problem with defining the mission and vision. When you manage to do this, the perspective of the people involved changes a lot, and many things are clarified. I recommend that you always think at the very beginning of the mission and vision and start conceptual work with them, and if you create a product and do not have its vision and mission written, do it as soon as possible…

For more exciting information on creating a mission and vision for a product, see.

Business goals

Technology should always support the business. Can they do this, since, during the development of the solution, the team does not know the business goals that are to be achieved using the product they create? How do these goals connect with the vision and mission?

Project Approach

We approach the earth from a high-level vision and mission. In the case of a project, it is usually a descent to the ground … and in 90% of cases, the goal for the project is to implement all functionalities within a set time and budget. Of course, we work agile, usually in some variation of the SCRUM framework adapted to the Scrum team. We are agile, but we still have in our heads that the most important thing is to do everything by the estimation and the set range. If it fails – the contract includes penalties that the customer can use.

Product approach

In the case of the product approach, you should always ask yourself what value will the work that the team brings. How can we measure it? Is it worth spending the money and involving a development team?

Defining your business goal behind is a good starting point, but it’s equally essential for you to be able to measure if you’re approaching your goal. You should do this by creating measures that will be signposted, showing whether you are approaching it or not. I recommend using the OKR method, which Cagan described excellently in the context of product development in the book Inspired.

OKR Method – Objectives and key results –

was proposed by Andego Grove named “the Father of OKRs,” and the most famous company with its use is Google, thanks to the initiative of John’s Doerra.

To understand Google’s significant impact on OKRs, let’s quote Larry Page’s Wikipedia:

OKRs have helped lead us to 10x growth, many times over. They’ve helped make our crazily bold mission of ‘organizing the world’s information’ perhaps even achievable. They’ve kept the rest of the company and me on time and track when it mattered the most.

 

OKR example?

 

Goal: I have to be in Amsterdam within two days

Measure: The distance we are from Amsterdam

Why is my goal important? This is my “why” because in Amsterdam there is a conference during which I am likely to sign a contract for 1 million euros.

The goal will be achieved when the distance expressed by our measure is zero. In addition, it must happen within two days.

The goal can be achieved in many ways, but we leave it to our team, which answers the question of How to transport us most effectively to Amsterdam in two days

Progress is measured by checking my current distance from Amsterdam, which shows all the time whether the gap is getting smaller or going to zero. If so, the team knows they are doing a good job. So, for example, he bought us a ticket for the right plane, train or taxi…

Yes, it is a typical example, but it captures the spirit of OKRs well.

How can you relate business goals to the work of your SCRUM team that is working on the product?

One of the methods is to link business goals with the sprint goal, which is one of the requirements for creating a good sprint backlog. Due to the frequent lack of understanding of business goals by the Scrum team, the sprint goal is rarely correctly defined. Roman Pichler perfectly describes this issue in the article “Creating effective sprint goals”.

If you manage to define goals and measures, magical things will happen. The scrum team will begin to wonder if what is in the product backlog should be implemented or something better. Isn’t it every manager’s dream for technical people to think that way?

How does this relate to the design approach in which we implement functionalities in a given time and budget? Well, in the product approach, the team and the sponsor have the same goals – focus on achieving business goals, rather than often different ones – where the development team wants to implement all functionalities, and sprints are used to divide the functional list into two weeks pieces…

A real-life example:

The team is working on an application whose task is to arrange meetings between people who privately deal with nail painting (service providers), and people who are looking for this type of service (clients). The team has a backlog of functionality for several sprints – they have used a design approach so far.

A meeting takes place, during which the team learns that at this stage, those responsible for business development have only one business goal defined as follows:

Goal: Increase the number of appointments in the application during the quarter

Measure: Increase the number of visits by 100% compared to the previous quarter

The team knows that 300 trips were made in the last quarter, so the goal for the current quarter is 600 visits.

The goal is crucial for the client because thanks to his achievement, another financing round will be launched.

At first glance, the scrum syndrome does not have much in common with this, but during a brief brainstorming, it turned out that ideas such as:

• performance of the function, thanks to which after registering in the service provider system, with one click, it can inform selected contacts from the phone about subsequent appointments made by clients using the application

• if the service provider in the app has few meetings and did not tell his clients that he is on the platform, we can send a notification to the service provider with a push to do so

• we can help the service provider add an Instagram link that will facilitate the appointment of people who are watching his profile

These are just some of the ideas, some of which turned out to be very simple to implement and implement. The product backlog has been turned upside down. The product owner was delighted with the team’s initiative. It soon turned out that the changes made had a significant impact on the number of appointments – which was measured using analytics in the Mixpanel tool.

The team has never returned to thinking in the category of further functionalities developed in the project. From now on, he focused solely on implementing features that bring the highest value and influence the achievement of business goals.

The goals defined by using OKR are applicable in many business contexts – I encourage you to familiarize yourself with them – as a starting point I recommend the Wikipedia page.

Budgeting

 

Project Approach

We set the project budget based on functional analysis or previously prepared full specifications. It includes additional risks that almost always occur, as well as the operational costs of running a project. Usually, the budget is fixed – just like the range of functionalities that we want to perform. Three main factors in software development affect project success:

• scope of work to be performed

• budget (linked to time)

• quality

Therefore, project owners are trying to negotiate as large a budget as possible to have the most exceptional comfort and minimized the risk of not providing the functionality or carrying out the project in unacceptable quality.

For larger projects, work on the budget is a factor that causes the very start time of the project to be extended due to the complicated decision-making process.

Product approach

We build the budget based on the business goals and benefits that we want to achieve. We offer budgets that are tailored to your goals. They should give comfort to the development team working to achieve these goals. At the same time, it should not encourage you to build products that have more functionality and are more complex and advanced than is needed to achieve business goals. It often happens that the amount of functionality is so large that they make it difficult to achieve business goals.

These goals should be as small as possible but defined so that their implementation causes business people to be interested in further investing in the product and feel the benefits as soon as possible.

It is exciting that even if 100% of business goals cannot be achieved. Still, the project sponsor was involved in setting the goals and measures, and the propensity to continue investing in the product is very high. This is due to hard data that shows that the team can approach its implementation effectively.

Time frames

 

Project Approach

In the design approach, usually, the release of version 1.0 of the application means the end of the project. Business owners often think that after the release of version 1.0, the project will go into service and maintenance mode, and the team that developed the product will no longer be needed. Most often, it turns out that users start to submit comments and ideas, and there is nothing else but to start another project – this time for version 1.1.

This involves passing the entire process typical of the design approach, which is expensive and long-lasting. In the end, it turns out that the team members are already on other projects, and new people need to be implemented, which further increases costs.

Product approach

The project sponsor and the team understand how the product life cycle works. The purpose of the release of version 1.0 – often called MVP is to start working on the solution by the first users called early adopters (people most interested in using the product who can get over the imperfections of its first version). The second goal – which is evident with the product approach, is to improve the product based on feedback from them continually. The time in which we make improvements is significant so that early adopters are the most satisfied.

As a team in product thinking, we know that we are still at the stage of verifying the main functionalities. The team is currently focusing on listening to users and responding quickly to their comments. We process applications that affect the achievement of business goals. At some point, we will reach the stage when the product is stable, and the users are satisfied.

Then we move to the next phase, in which we expand the group of users to the so-called “early majority”.

I encourage you to read the description of this process in the book “Crossing the Chasm” by Geoffrey A. More.

Success

 

Project Approach

In the design approach, the team and project sponsor usually have different definitions of success. The team focuses on performing all functionalities by the agreed scope and documentation. The victory for the client is to achieve the business goal, which is one of the elements of the application created by the development team.

When designing, it is very often impossible to combine both definitions of success into one, because rarely, the implementation of all functionalities specified before the start of the project guarantees the achievement of business goals.

Most often, it turns out that at some point during the project, we start to collect a lot of feedback from users who see the application for the first time. In the design approach, where we have a set budget and a list of functionalities, it is tough to manage it and start making changes – because everything is predetermined and unchanging.

Therefore, it finally turns out that after the release of version 1.0, we have a solution that does not meet the needs of recipients, and the entire budget has been spent.

Product approach

We measure success by achieving business goals. The scrum team decides which tasks have the most significant business value at the start of each sprint. It is based on known business goals. If new requirements appear during the work on the product, the team does everything to take care of their implementation in the next sprint and release it in the next version of the product as soon as possible. In this way, it supports the implementation of business goals.

Sometimes it happens that after spending the entire budget, some of the functionality from the original project specification has not been implemented at all. Still, we are much closer to achieving business goals, and users are fans of the created application.

Risk

 

Project Approach

In the design approach, we eliminate risk when it is possible to accurately predict the final result during the analysis and design of the scope of work. It is difficult because software development is creative work that deals with solving complicated and comprehensive problems. This issue is very well described in the cynefin framework, which was proposed by Dave Snowden in 1999.

It divides tasks into four types:

• simple (obvious)

• complicated

• complex

• chaotic

Added to this is the Disorder area – these are issues that cannot be assigned to any of the above four types.

Tasks that are solved in software development usually belong to the areas of complexity and, at the same time, complete tasks.

Quoting Wikipedia:

The complicated domain consists of the” known unknowns “. The relationship between cause and effect requires analysis or expertise; there is a range of right answers. The framework recommends” sense – analyze – respond “: assess the facts, analyze, and apply the appropriate good operating practice. [2] According to Stewart: “Here it is possible to work rationally toward a decision, but doing so requires refined judgment and expertise. … This is the province of engineers, surgeons, intelligence analysts, lawyers, and other experts. Artificial intelligence copes well here: Deep Blue plays chess as if it were a complicated problem, looking at every possible sequence of moves.

For this, comprehensive tasks:

The complex domain represents the” unknown unknowns “. Cause and effect can only be deduced in retrospect, and there are no right answers.” Instructive patterns … can emerge, “write Snowden and Boone,” if the leader conducts experiments that are safe to fail. “Cynefin calls this process” probe – sense – respond “. [2] Hard insurance cases are one example.” Hard cases … need human underwriters, “Stewart writes,” and the best all do the same thing: Dump the file and spread out the contents. “Stewart identifies battlefields, markets, ecosystems, and corporate cultures as complex systems that are” impervious to a reductionist, take-it-apart-and-see-how-it-works approach because your very actions change the situation in unpredictable ways.

The cinefin framework proves that it is difficult to accurately predict and estimate the duration and final form of tasks that are considered complex or comprehensive.

If we consider the difficulty of accurately specifying functionality with factors that affect the success of the project, which are:

• scope of work to be performed

• budget (linked to time)

• quality

We will conclude that with a fixed budget and the desire to perform a full range of work, which is probably not well described – quality will suffer.

Product approach

The underlying assumption of the product approach is to minimize the risk at every stage of product creation.

The risk is spread over all phases of the product life cycle. Thanks to this, you have more control over it. It consists of the fact that you should verify, as often as possible, whether product development is heading in the right direction. If this is not the case, then you make changes.

Often, teams that work on IT projects and use agile methodologies such as SCRUM have the problem that they don’t use risk spreading. They add a list of functionalities specified in the product backlog before the start of the project, divide them into sprints, and work on the following features in each sprint to announce at the end of the project that everything that has been specified has been implemented.

One of the primary purposes of using the SCRUM methodology is to minimize the risk by not performing tasks by the team that does not provide business value. Therefore, the product backlog should always be sorted according to the business value of individual items and in the sprint, realize what will bring the highest value at a given moment.

Often during the project, it turns out that the requirements change. The often prepared specification does not include some criteria. According to logic, all stakeholders should quickly agree to change the scope of ongoing work and focus on what brings the most significant business value. The backlog should remove those tasks that will not add value.

Teams

 

Project Approach

People are assigned to the project for the duration of the schedule. This is usually a short time perspective that does not positively impact long-term commitment to product development. Instead, the team takes responsibility for the implementation of all functionalities that have been provided for in the budget and scope. They do not focus on long-term business goals – usually, the only goal they have is to put the application in version 1.0. And project completion.

Why is this happening? Because they know that they will be transferred to another project, and someone else will take care of it … The project team usually does not cooperate with the business. He knows nothing about the business goals pursued by those responsible for business development.

Product approach

Team members know the product and identify with it. They know that they will work with him in the long run and focus on achieving success, which is synonymous with achieving business goals. This is an entirely different perspective. They know the vision and mission, the goals that everyone aspires to.

The team knows that their success is not about completing the functional list, but about achieving business goals that they understand well and are willing to support. They also know the way to achieve these goals – they know what is used to measure progress in achieving a goal. People love to identify with the things they create in the long term. The likelihood of identifying yourself with a product is much higher than with a design approach.

The observation made by Marty Cagan in the book Inspired is very apt. He points out that – most often, it is the members of the development team who propose interesting functionalities that support the achievement of business goals. This is in contradiction with the frequent thinking that the business world is far from the world of development. Take advantage of it! Don’t let your development team think about progress through the number of lines of code written or application views.

Priority

 

Project Approach

Even when we use the Agile approach, projects are built based on the project plan, schedule, and requirements that were defined at the beginning of the work. The range is constant and unchanging. In most cases, prioritization consists of arranging the work in the project to provide the following functionalities in turn.

Very often, this approach does not support the achievement of business goals. Sometimes a roadmap appears, which is a kind of wish list to be performed in the coming quarters. These are the premises for product thinking, but it often turns out that the roadmap can be thrown away three months after its creation. It’s been out of date for a long time.

Product approach

As I mentioned before – we focus on achieving business goals. We measure using measures. We move away from a typical roadmap and treat it as a list of more considerable functionalities – often called epics, whose value is analyzed in the same way as the value of every other item in the backlog. If we find that it is worth taking a position from the roadmap, we start to do it. The business value guides us on what its implementation will bring.

You must understand well that the business value of a given item in the product backlog changes over time.

Example:

Let’s return for the moment to the described application connecting service providers with clients in the beauty market.

What is more valuable?

Implementation of functionality that will increase the likelihood of making subsequent visits, or an update of the expo library (used when creating the application in react.native)?

At first glance, the team should look at the functionality that increases the likelihood of making an appointment. However, what if it turns out that the used expo version will cease to be supported during the next month, and without the update, we will not be able to release the next version of the application? Simple conclusion – the business value of the export update is higher than any other work done by the team.

Visibility

 

Project Approach

An approach in which, after business approval, the project goes to a black box called a development team or IT department. Often, with the expectation that a solution will be created that is faultless, it will contain all the requirements that were defined in the budget set at the beginning. Sometimes, as part of keeping order, the project sponsor will occasionally look at what the team is doing, and pay attention to something so that the team feels that they are interested in the project…

Product approach

Full transparency, thanks to the appropriate definition of business goals and measures that are available to everyone and are understandable. The task of a business is also to support the team in continuous analysis of what is worth working on and which ideas can help in achieving business goals. Transparency at this level guarantees that we are all working on the same purpose, and together we come up with the best solutions. Thanks to the ability to measure progress, it is easier to conclude and not waste resources.

Summary

Nobody likes to do things that nobody needs. This statement is a truism, and everyone will agree with it. If so, why do so many projects fail, so many resources are used optimally?

One of the reasons is to focus on working hard instead of focusing on the goals we want to achieve. Product thinking helps a lot in this – it requires long-term looking.

I hope this article will help you make better use of resources and achieve ambitious goals that you will be satisfied with, which I wish you all.