Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


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


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


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Product Orientation is old-school, and still relevant

    by Nick Beneker,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    At the risk of sounding like an old fuddy-duddy, IT teams used to be organized around products. We called them application suites. Major projects, small enhancements and fixes were all done by one team, focused on the needs of a business unit, function, or customer capability. Now the problem was that while product and customer knowledge was high, innovation was low and individuals felt like there was no career growth, as they were too knowledgeable and too valuable to let go. So companies moved to the other extreme where everyone lived in resource pools and was assigned to individual projects based on skill set and availability. Now, no one feels like they have a home, and the issues raised by the author arose. Wouldn't a hybrid approach be best? Organize around the product, but bring in specialized expertise to foster innovation. Develop a personnel rotation plan that ensures that a percentage (20-25%) of the team has the opportunity to move to another team - this promotes sharing of knowledge and best practices, and allows for individual growth.

  • Re: Product Orientation is old-school, and still relevant

    by Ardita Karaj,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks for this comment Nick.
    As I read your comment there are two points that jump up for me:
    1. Innovation
    2. People’s growth
    Innovation: I have been lucky to work on the type of organizations you mention where people and work was product based and teams were organized around customer value. But I had a better experience regarding innovation, that company won an Oscar for Innovation in Technology! We attributed this to the close collaboration of product managers, developers, designers and managers within our company as well as extending this collaboration to our customers, being part of their challenges and partnering on how to solve them. I believe other organizations that didn’t have collaboration tried to create it in small project-by-project based type of working. Innovation in my opinion is not something you get by putting money on an “innovation project”, it is rather something that happens naturally and continuously when people work together for a long time and understand well the purpose of their work and the value they bring.

    People’s growth: I believe this is very important topic and almost all organizations struggle with this on-and-off. Many methods and examples are tried and they work for a while or under certain cultural conditions supported by leaders. Specialist (not generalizing specialists) are very expensive and we can’t afford the risk of having knowledge in one person’s head. I was careful to use the term “long live teams” because I do believe that a group of people need a reasonably long time to become a performing team. At the same time we need to understand that people are unpredictable and we need to create space for them to say “I like this but I am intrigued and interested to learn about that” and create chances for them to move from one team to another. I agree with you that like this they learn more and become (what we refer to in Agile community) a T-shape person, generalizing specialist. Teams with higher number of generalizing specialists have less dependencies from others and are able to move forward faster. I like it when this is done naturally and supported within certain boundaries that do not hurt the teams they are leaving or create chaos on the new teams they are moving to.

    The hybrid option you mention here, from my point of view, is a product based model with a lot of collaboration internally and externally. It is a model where people know the purpose of their work and the value they bring, they have space to grow and learn in areas they are interested and bring innovation by cross-pollination.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p