Transitioning from startup development-mode to iterating a software product

Building a new product likely means you're building as quickly and as scrappily as possible to get to market. For a web app this is usually a short push of 2-4 months and If you're successful you now have a product that needs to transition to a more sustainable style of development.

Here are some of the things I've observed or implemented to make this transition deliberately. Hopefully there are some things here you can use to prepare yourself for transitioning your next successful project!

The team needs to decompress

With any MVP or initial build there's never enough time to get the level of fidelity you want. When an engaged team with high standards faces this problem they tend to work a bit harder to complete the work to their high standard.

In software this is called the "crunch". Crunch varies in intensity for different orgs and projects. Crunch is usually used to refer to a management dictated crunch but in my experience there is usually an self-driven crunch in all highly engaged teams that happens with no direct management pressure. Great people will want to do great work irrespective of time constraints.

Either way, crunch is an undesirable state and you want to keep it as short as possible. If you can avoid it completely you should but that's unlikely to happen.

If we assume that there has been some crunch by your team to get a product out then you need to let them decompress now.

You have to talk about this change and normalise it. Remember that it's difficult for a high performing team to go from working intensely back to a more sustainable pace. Empathise with your team here, they probably feel like they're suddenly not doing "enough"!

As a guideline it will take at least half the time again that was spent in crunch to normalise the usual pace again.

Revisit and reiterate the why with your team

Now that the MVP is in the market and you are learning from real customers it's important to go back to the original hypothesis and measure the effectiveness of your solution. It's very likely you had an incorrect hypothesis at this stage but that is normal and what you do have is a successful learning.

When you have a new direction or focus for the product make sure you share that with the team! Share it regularity and consistently. The team have likely been running with a mission of "get what we promised done on time". This is only useful in the short term. You need to get the team behind a genuine mission that they are passionate about to maintain engagement.

Encourage cleanup and tidy up of the existing work

With an MVP but you actually want to take on a certain amount technical debt. This is healthy debt like a mortgage or a business loan that provides capital so you can reach the next level. It needs to be managed but it will be present in your MVP.

Specifically spend some time reassessing the technical debt you took on and align it with the new "why", the new goal for the product. There are likely parts that the development team feel uncomfortable about and these are great little projects to let the team decompress with.

In particular look for things that affect everyone on the development team. Some examples might be rebuilding the CI CD pipeline for the next phase of a project or growing automated test coverage around tricky parts of the system that were skipped over in the rush to market.

These kinds of technical debt paybacks will amplify the productivity of every team member for the rest of the product's lifetime and act as a solid hedge against technical debt that isn't worth looking at yet.

Change the focus from pure output or "tickets per week"

Again, it's likely that the team has been running to get "everything done on time". This is a very functional output focus that is useful for a crunch type situation but it's not good in the longer term. You want to work at changing this focus on output to the ancillary things that are important for maintaining a software product.

It's likely that you want to re-emphasise non-functional things like quality and performance in order to balance functional and non-functional output in a team that has been focused on functional only.

Even for the functional improvements you will be making to the product you should match them back to the "why" and start there and focus on solving those problems rather than ticket throughput. Move the discussion away from working hard to working smart.

Audit your processes

The processes and norms that have developed in the team might not be suitable for longer-term success. The process used by a project team should be relevant to the factors associated with the team and the project.

If the team was building something new before then they probably need a different process if they are iterating on an existing project.

Just as an example you probably had very short time to make decisions about anything in the crunch time. So you had short meetings to make decisions or even just one person making decisions on the fly and you went with it. This is fantastic for momentum.

If you want to have higher quality decision making you might want to get more deliberate and collaborative. This could just be longer meetings with a wider set of people and knowledge available but could also extend to writing up the problems and potential solutions in a wiki document. Then sending this document out to the team to give them time to think things through before getting together around a white board.

You have time now, and although you want to maintain decision speed there are probably some topics where you would get great input and higher quality outcomes by including the entire team in decisions.

You should pay serious attention to the items discussed in retrospectives. For each item analyse the impact on the team. Identify the things that affect the entire team rather than one person and focus on those. Don't ignore things affecting one person but for the purposes of this article just focus on the items with wider impact.

Any highly performing team should have a process for continually improving on their processes. The product and the team will always change so the processes must change with them. It's important to show that based on retro feedback there can be genuine effort in trying new things so that there is a way out of the crunch or any other undesirable situation. Show that the team has power to change things.

Keep improving

This isn't a once off thing to focus on. Any team and even individual team-members will bounce between "crunches". But you should be particularly aware of this transition for greenfield projects and MVP-type projects moving into a long term development process! Good luck!