BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Think in Products, Not Projects: Q&A with Ardita Karaj

Think in Products, Not Projects: Q&A with Ardita Karaj

This item in japanese

Lire ce contenu en français

Bookmarks

Organizations structured around products oversee their work end-to-end. Reversing Conway’s law to establish long-lived teams around the products brings stability and makes it easier to manage and prioritize work. Retrospectives are a powerful tool for product management; they give you the confidence to continue and help you pivote quickly on what might become high risk or loss for the organization.

Ardita Karaj, agile coach, trainer, speaker, and consultant, will give a talk titled "What’s my product" at eXperience Agile 2018. This conference will be held in Lisbon, Portugal, on October 1 - 2.

InfoQ will be covering eXperience Agile with Q&As, summaries, and articles. This year’s conference theme is Improving Through People:

Discover the latest cutting edge Agile practices by top industry leaders from around the world. eXperience Agile is more than just another Agile conference. This is an event that will bring the most revolutionary applications of Agile being used today.

InfoQ interviewed Karaj about why people in organizations think in projects and the problems that this causes, how thinking in products helps us to find better ways to do our work and improve continuously, how agile retrospectives relate to product thinking, and what organizations can do to change project thinking into product thinking.

InfoQ: What will you bring to this conference?

Ardita Karaj: In this conference, I will run two sessions. The first one is a workshop to help teams new to Agile to start an agile project, by bringing focus to value, customer and collaboration. The second session is a continuation of the first. Usually we see results with the first Agile project and we get in the routine of repeating the same things and expect better results, project after project. We forget one of the agile foundations "Inspect and Adapt". I believe organizations needs to learn with agile projects initially but then they need to inspect and adapt to better ways, which are product/service/customer journey based.

InfoQ: Why do people in organizations still think in projects?

Karaj: Depending on the organizations, it is easy, hard or very hard to not think in projects. This is due to the fact that these organization have operated for a very long time in this fashion and have created a structure that supports and protects this model.

Funding is done based on projects, people are allocated based on projects, forecasting and targets are set based on projects. For an organization to switch and operate in a different way, a lot of structures need to change. Structures like Finance, HR, Business and Delivery teams, Facilities, Operations, Marketing, Sales, etc. We need to change the relationship between Business and Development/IT/Operations and this concept where areas of the same organization are considered "Cost Centers", rather than partners.

These are not easy changes, and require strong and educated leaders. I have met executive leaders who understand in principal the value of the change, but are not able to execute on it during their short term in these roles. It requires a lot of work, dedication, low tolerance for politics and time invested. And these are often too big of a challenge for organizations to face. So they take the path of getting small improvements by continuing with projects (in the best case using agile), knowing they are not reaching their full potential.

InfoQ: What problems does this cause?

Karaj: In a high level, projects are local optimization efforts. We get a group of people who create new (or improve existing) functionality for our customers, and then we pass that onto a team that has no idea why the change was made and how this change was solutioned/implemented.

Very often, the quality is low and this Maintenance team needs to deal with the issues. This creates a culture of tolerating low quality, accepting that maintenance/operation teams will deal with problems created by delivery teams, not allowing delivery teams to learn from their mistakes (and hence keep repeating them), allowing budgets to be set without proper data, treating people like easy-to-replace objects, and so on.

This culture is ok with low expectations and tends to increase debt in many aspects like technical, product, talent, innovation, etc. As such, these organizations often run in reactive mode and are constantly catching up with what the competition has brought to the market. Changes are expensive and take too long to get in the hands of the customers.

I'm not sure about you, but personally, I wouldn’t like to be part of such an organization :) I wouldn’t feel proud of what I did and I would be worried about the life of this organization.

InfoQ: How can thinking in products help us to find better ways of doing our work and improving continuously?

Karaj: Organizations that are structured around products (or services) have an advantage because they are structured to oversee their work end-to-end, which means from idea to client and close the circle back with a new idea based on the client’s feedback or reaction. I say this because teams are accountable and have ownership of the solution offered, the quality delivered and customer experience and satisfaction.

By having visibility in all the areas involved in delivering value we can understand the product and the delivery process, identify bottlenecks, allow for the voice of the customer to be heard, collect data and over time make better/smarter decisions. Business will be able to understand where the invested money goes and better forecast the expected impact to sales. Marketing and product management have a better sense of the capacity of the organization and must make intelligent prioritizations and shift toward experimentation of features and services. Like this, we can reduce the risk of delivering low or no value to customers.

Another positive element in these structures is the sense of long-lived teams. These teams bring one element of stability in a business world that has many moving targets and many decisions to make. We know what the cost of each team is over a month, we know the cost of resources (I am not referring to people) required to keep the organization running, and as such, we can now bring more focus into managing and prioritizing the work. Long-lived teams have the chance to test and learn, to inspect and adapt, innovate and break molds to create better products and structures.

InfoQ: How do agile retrospectives relate to product thinking?

Karaj: Retrospectives are the core of "Inspect and Adapt", "Continuous Improvement", and "Continuous Learning" and other similar practices that are strong elements of products that perform and compete strongly in the market.

A product management team that does not stop to evaluate what customers value or dislike, how features and services are leading in the market, or how competition is getting ahead, how much customers are willing to pay for certain features and how some other features are only adding into the delivery cost and maintenance, would be managing their product blindly.

Without the space to stop and look at these elements, without the courage to face challenges and what’s not working, without the discipline and proper attention to the state of the products and services, it becomes difficult to create products that customers are willing to buy and eventually to keep an organization financially strong in the market.

Being able to have the confidence to continue on what you are doing or pivoting quickly on what might become high risk or loss for the organization, is one of the most powerful tools product management teams can have.

InfoQ: What’s your advice for organizations that want to change project thinking into product thinking?

Karaj: Some of the product organizations that do this well and intentionally refer to the Conway’s law that links the "shape" of the software with the shape of the organizational structure. Reversing this law helps these organizations to structure their teams in a way that offers higher focus to customer experience.

Any organization that is heavy on projects and is not able to answer clearly what their products are can use the reverse Conway’s law to start the change toward product thinking. Focus on the customers, understanding their needs, their pains, their gains.

At the same time look at the market trends and what your customers are using or testing in parallel to what you offer. From here, start with giving sense to your services and features and start to create teams that support these features or services end-to-end. Test all the areas of your organization that are related to the delivery of these features /services and make changes that might seem small, but allow for faster flow of the idea to the hands of the customer.

Listen to your people, and to their improvement ideas, and give them space to learn during this change. You will need to have the support and collaboration of many areas of your organization. As I mentioned above, it is not easy but it can be done. And once you have one good example of this, repeat with improvements. If you are doing the same thing six months down the road, you are doing this wrong. It would be time to stop, retrospect and adapt.

Rate this Article

Adoption
Style

BT