Doing Products instead of Projects

Recently I’ve been involved in managing several teams who are making their move from running as project teams to product teams. Today I am taking stock of what this might involve and looking at how people respond to the change. This is the result of 4 months of solidly running with products.

Some Background

As with a lot of organisations, spinning up large capitally-funded technology projects is the de facto standard on how things get done. Sneaking through the gaps of governance, small things get done with agencies to tactically deliver some work. Both of these approaches can be unsustainable, as both large projects and small initiatives can leave behind technology solutions that people don’t tend to know much about and who aren’t formally allocated to maintain.

Sometimes it’s tough to change the approach in some orgs when long established processes and governance remains firm. The amusing result is that it’s often easier to ‘hide’ costs through high-effort manual tasks completed by staff (represented by salary costs) rather than paying for a service from a vendor, which is inherently made far more visible through a series of invoices in an ERP system.

So, in light of this, some organisations operate under a product mindset. It’s probably more familiar than you think!

Product, what does it mean?

For organisations, the product is usually a good or service ‘sold’ via a transaction to a consumer to achieve some purpose and benefit. Sometimes the transaction or sale might not even involve money: it could be the product is exchanged for personal data, eyeballs on advertising or other kinds of revenue models. Some organisations might not even make a cent but instead operate with a target of reaching a number of users. The specific target is important so you can train your model much like you’d train a machine learning model, just over a longer period of time!

Forming a team around a project with a fixed amount of funding to achieve some outcome is probably the simplest approach but it’s certainly not the only way. Imagine if the Google web search experience was only ever funded in large unweildly batches of funding which are released sporadically over the lifetime of the search service. The lack of ongoing support and continuous improvement would stifle the development and feature release of the product.

Sustainability is a word which often comes to my mind. Bidding, running and closing out projects to move technology forward is extremely unsustainable. No technology requires zero maintenance, especially when it’s key to operations, sales or otherwise. Everything needs to be tested, upgraded and decommissioned at some stage. Sometimes this is handled as operational expenditure, but this may not achieve a level of dedication that technology deserves. The rather large initial investment is not maximised over the lifetime of the technology and every upgrade is met with dread!

I could probably write a whole article on the role of sustainability and why it’s often forgotten (especially when making decisions and keeping support/operations on your side). Another blog, perhaps?

No no, really, what is a product?

I’m going to conflate ‘product’ and ‘platform’ for the sake of simplicity for now.

A ‘product’ could be many things, but some real examples which come to mind are:

• A mobile phone app which allows people to keep in touch with friends
• A central content management platform which runs 50 different websites for a company
• A range of exercise programmes which are controlled through voice on various smart speaker platforms

Some key elements of products are:

• Long-lived (let’s say 3 - 5 years)
• Continuously measured
• Continuously improved in response to feedback, measurement and changing market (including external factors)
• Have a natural start, release, maintain and sunset profile which is longer (but not necessarily slower) than a project
• Require skills from many different disciplines to come together
• Have a defined list of things to work on (such as a backlog) and a high level roadmap (with less detail as you look into the future)
• Can be autonomous in decision making (self-directing, self-sufficient)
• Developed by teams who are deeply interested in running experiments to learn more

and…

• Funded for the lifetime of the product (subject to regular reviews of course!)

The most interesting thing is that a product doesn’t have to be primarily what the company might sell. It could simply be an internal platform which helps other teams or other products. In this situation, the product/platform can still be run as a product, just with internal customers.

How do people respond?

I’ve spoken to many people on the topic, both in “at the pub” style open conversations as well as in a more professional setting. The response is pretty much in one of three camps:

1. Embracing: This is an uplifting mode of operation.

The best one!11!!!!11ONE! How could you operate any other way?

Ah the evangelists. These guys are the keepers: they will keep you going in tough times and prove that given enough patience, the model can work.

Not everyone gets it or is on board from day one, but for those who are: you’ve succeeded. Hold onto those successes. They will assist with people in a…

2. State of Confusion: How is this different to before?

Probably the easiest one to fix, although sometimes it just takes time. Some of the variations on the state of confusion could be:

• Teams might already operate in this fashion, so calling something new or a change of how to approach something when there is little or no change
• BAU or operational teams with a variety of “keeping the lights on” style activities which must continue and don’t neatly fit into nicely defined products
• Delays, disruptions and mixed messages about how and what to work on
• Campaign driven activity which doesn’t run all year round

3. Rejection: I cannot see how this could work.

Unfortunately, this is always a potential outcome. The key is, of course, to minimise this! The rejection response is generally experienced when a more extreme state of confusion is involved. It can also be a factor when attempting to elicit change in rigid processes, such as funding approvals, or it could simply be because people have spent so much time working in different models that they cannot see how a new model could possibly work.

What makes a successful product team work?

To concentrate on successes, it’s interesting to ask your teams how they think they’re going. I asked the members of two teams I work with closely and here’s what they had to say.

The engineers said:

We have the expertise in the team to build stuff and get it into production!

We’re solving interesting problems in a modern codebase

We put emphasis on getting working code into production

We are respectful to each other

I actually really like the last point: the teams that work the best have ultimate respect for everyone in the team, regardless of technical proficiency.

I quizzed some more teams who are seen to be performing well and their feedback had a real theme about it: it was all about team culture and how they made effort to make it their own.

Some examples of this are:

We are having an avocado seed growing competition

We have a strict “no arseholes” policy

We have fun and like our space - we can decorate it anyway we like

We share fruit with everyone

We get along well and solve issues as a team, help and support each other, no dramas only awesomeness

We believe in team interactions and bonding through activities like boardgames (Secret Hitler), Team lunch, coffee and going to the gym together

I have noticed that the teams who are doing well grow plants in the office as a hobby. A coincidence? Surely not!

Speaking process for a moment (it creeps in occasionally), some teams were finding retrospectives to be useful:

Fortnightly retros allowing us time to identify what’s not working and discuss ways of changing it

We have PRs (pull requests) and this gets everyone involved (we do peer review meetings after stand-up everyday)

I won’t forget for a moment that I got far, far more quotes about team culture (and awesomeness) compared to talking about the products OR the processes!

Common Team Elements

Apart from the common themes about culture and respect, there was also an interesting overlap for the teams who are succeeding at delivering products. They share some common elements, which I have observed:

• The teams are newly formed (within the last 6 months), although the team members are a mixture of new and existing staff
• The products are also fairly new in the market (with an MVP recently launched)
• The teams have a balance of permanent employees and fixed term contractors
• The technology is good: it’s not legacy or antiquated and it makes solving problems easy and satisfying

Some opportunities and challenges

Proving this model works can be challenging in large organisations. Here are some things I’ve observed:

Clashes with funding models

Products dictate that they live for a longer time: 3-5 years is the rule of thumb. But often funding models are tied to financial years, which can create conflict and uncertainty. It extends to how team members are funded because you really want more permanent staff on the books and less short-term contractors in this model, to keep things running smoothly with less staffing changes.

This quickly leads to…

Trouble gaining approvals

How can the financial controllers be sure that something will come at the end of it all and every dollar spent was the right way to spend it? Will we get funding again next time? I think these problems can be solved through proving value as early as possible by delivering visible solutions, especially when they can be measured and reported. But it must be said that this model can often be quite new for upper layers of management.

Responding to resource changes

If you operate in an environment where money is super tight OR it’s really hard and time-consuming to hire new talent, be wary. The product model is not kind in this environment because significant changes to one product team may ripple across multiple teams and it’s very difficult to backfill staff. Teams will no longer be self-sufficient, self-directing and long-lived because external factors will greatly influence the team and override team-based decisions. This will undermine the team’s sense of control and can make them doubt the model. A number of scenarios can bring about this, such as changes to leadership, general team movement but also long periods of unplanned leave.

Measuring success

Nothing would be worthwhile if you’re unable to measure the success of such a large change to an organisation. This could take time and a few different ways are on offer, including:

• Engagement surveys
• Team health-checks
• Metrics on delivery and quality
• Customer feedback
• Ultimately, increased profit/results/businessy things

Be prepared to change the model up, even only for select teams, if the signs aren’t good. But that’s all in the fun of it: if the products are expected to continuously measure and improve, so is the product model and team structure!

Faking it

I really think that if you want to try the product operating model, go all-in. Don’t fake it, withhold information or pretend teams have control and responsibility when they don’t in reality. There really needs to be support at all levels of the org for this to be a success and we all know that takes time, but it’s certainly time well-spent.

In the process of writing this blog…

… I discovered others in the team had also thought about what makes a team feel successful. Have a read of Simon’s blog here for a more detailed developer’s perspective. His GIF animations are also better!

Wrapping up

So I haven’t actually mentioned some familiar terms: nothing about agile, scrum, kanban, extreme programming, lean, or other approaches. You can certainly bring your knowledge of any of these approaches and apply it to the product model.

The most interesting discovery for me is that the product model is great at responding to changing needs of the customer, it’s good at responding to changes in market, it’s average at responding to changes to funding and major changes in teams. In some ways, the model is intrinsically accelerated and constrained by how well you can set up and maintain your teams. It would be interesting to consider what models do cope well with these kinds of changes, or what tweaks are required to improve the model in this way.

If you haven’t already tried, how can running things as products instead of projects work in your organisation? If you’re already there, what makes it work and what would you change?

Comments (0)