We tend to believe that every new feature is a good and valuable addition to a product. Quite often, it can be hard to not implement a feature, especially when you’re constantly hearing good ideas for new features every week.

The problem is that every new feature adds debt or creates a placeholder for future debt. You deliver more and more features, accumulating more and more debt. Most people don’t know how to work with debts. I don’t. Everyone knows about technical debt, but there are few more types of debt in software development:

• Functional debt. The needs of users are changing, but the system forces them to follow old flows, and doesn’t cover new cases.
• UI debt. Over time, the user interface can lose consistency and coherency, making the system harder to learn and understand
• Quality debt. Bugs are ignored, the system shows unpredictable behavior, experiences errors, crashes
• Technical debt. Architecture and code quality slows down development.

Any new feature in a product may become a source of all these kinds of debt.

The image below shows several features in a product. Every feature adds some debts. In reality, it is extremely hard to add a feature with zero current and future debt.

Every Feature needs maintenance: functional, UI, quality, technical, documentation, localization. What if you have 100 features in a product? What about 1000? Can your software read emails already?

New Feature vs. Debt Payment

When should you add a new feature, and when should you pay back some debts? Let’s check the product lifecycle. Imagine you are running a very young startup. You don’t care about debts at this stage. You care about market expansion, new features, and growth. Now imagine the product is dying, it is too late to focus on debts, it’s over.

It seems the right time to focus on debts is when a product has proven its success on the market and is about to enter the “mature” phase. For a typical SaaS B2B product, this may be after 4-8 years. The chart above is valid for our SaaS product, Targetprocess. In my opinion, we started to focus on debts about 2-3 years late. We're finally coming over the hill, but it will take some more time to re-energize development.

Ideally, some part of your resources should be dedicated to debt payment at all times, but after 6-8 years it may even be a good idea to have a “Debt Return Year” or something. At this point, development speed decreases due to technical problems: UI consistency degrades, many features are outdated, bugs and performance issues annoy customers.

Moreover, you’ve accumulated enough customer feedback and now understand your domain much better. Mistakes you made and new opportunities became more clear. You need an ultimate clean-up to prepare a launching pad for a powerful push.

It is extremely hard to slow down and clean up the mess in a product. You are always afraid to lose market share and functional edge. I don’t want to be extreme here, just want you to think about every new feature you add from a debt perspective.

What to do?

There are several obvious consequences.

• Build small systems. If you need a large system, build several small composable systems.
• Less features -> less debts. Someone asks for a new feature? Default answer is “No”.
• Modularization is desired, since you can re-write modules to pay back debts and reduce side-effects. This means you can have more features in a modular system with the same level of debt as in a non-modular system.
• Remove rarely used features. When you remove a feature, you remove all related debts.

I want to finalize my post with a quote:

One thing that UNIX does not need is more features. It is successful in part because it has a small number of good ideas that work well together. Merely adding features does not make it easier for users to do things it just makes the manual thicker. The right solution in the right place is always more effective than haphazard hacking. — Rob Pike & Brian W. Kernighan

I’d like to shed some light on our current focus and plans, and what we are doing right now to help you be more productive in the future (that’s why Targetprocess exists, after all).

We have four major goals:

#1 Targetprocess platformization

Targetprocess is ten years old now, so you can imagine it has quite a lot of legacy solutions. Legacy slows down development and we can’t react to your requests in a speedy manner. It is hard to add new features that extend Targetprocess' domain. For example, it is quite hard to add Vacations tracking, or a decent Portfolio layer. We have to surround Targetprocess with services and make it possible to create Apps on top of the Targetprocess Platform. This platform includes a new microservices infrastructure, UI components (new Lists, Boards, etc) with defined extension points and a clear API, new Events Streams, Custom Business Rules, and other services. We have 3 development teams dedicated to this platform (~15 people in total). We expect to see first results in Q1 2018, since this is a challenging engineering task.

#2 User experience improvements

UX design includes fighting complexity, and improving UI consistency and predictability. We think this theme is the most important tactically, since the main problems with Targetprocess are caused by its complexity. Here we are going to improve navigation, fix WTF bugs and problems, improve collaboration via in-app notifications, implement Undelete, and fix the things that annoy you about existing features.

Three development teams (~20 people) are dedicated to this UX theme. We gradually release something in this area every two weeks.

#3 Visual reports

One development team of six people is dedicated to visual reports, because we think analytics is very important in any serious project management system. You've seen many improvements in this area, and we've just released Historical reports, which include Custom Burn Up and Burn Down charts, Custom CFD, Flow Efficiency, etc.

We will continue to improve this area for at least 6 more months.

#4 Fibery

One small development team of 5 people is dedicated to a spinoff product in the work management area. We’ve accumulated enough knowledge about how people work. So, we've started a new product from scratch that should provide an unmatched work management experience to companies.

The main idea is to create a product that grows with your company, that doesn’t force any practices and processes, but follows teams' processes naturally. You can read more about Fibery here: http://fibery.io. We will be releasing a private beta for Fibery around Q1 2018.

This chart shows how Targetprocess and Fibery overlaps. Basically, Targetprocess is focusing on medium-to-large IT-companies that create software products, while Fibery will focus on small-to-medium non-IT work management, like HR, Marketing, etc.

We are starting a Targetprocess UX Community in Slack. The main goals are to have a real-time communication channel with customers, share our solutions to problems, and get feedback.

We want to set up a place where customers can freely share and discuss major pain points with each other and shape the future direction of Targetprocess.

What we will do in the Targetprocess UX Community:

1. Share concept solutions, sketches, prototypes, and ask for your feedback.
2. Post quick news and updates about our progress in various areas.
3. Find people to participate in usability testing of new features and solutions.
4. Discuss problems and find solutions with your help.

Join the Targetprocess UX Community at http://slack.targetprocess.com. Share your pains, give feedback, and shape Targetprocess.