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.

In June 2016, we switched most of the people inside our company to open allocation. They have the freedom to start their own initiatives that are aligned with the central goal of providing a better user experience and fixing critical problems in Targetprocess product.

10 months have passed, and we can now analyze the experiment results. In this post I'll share my opinion about the experiment and mix it with the opinions of the people who participated.

Deadlines

Here is the current initiatives Roadmap. A very good thing is that almost all initiatives were implemented on time. It means people respected their commitments and did their best to keep promises. A bad thing is that some of the implemented features were still not deployed to production servers due to huge infrastructure changes caused by the microservices approach. Basically, you can't give a promise to release something when the infrastructure is not ready.

Another trivial observation is a struggle to fit R&D activities into the Initiatives model. If a team doesn't know how to attack the problem, it created "Research initiative", thus we timebox research. Then, when a solution is found, the team starts a usual Initiative with the results.

Overall, we wanted to solve the problem of speedy delivery, and we got mixed results. Yes, most features were implemented on time, but the infrastructure held them back.

Small Lesson #1. People don't like deadlines, but... deadlines work (when you have no problems with infrastructure).

Deadlines lead to cut corners, worse quality, and poorer solutions. In my personal opinion, this is not a huge problem, since you always have to balance quality and time. Estimates are not forced and, overall, teams have enough time to complete features with good quality.

Freedom of choice

Freedom boosted motivation. People were more enthusiastic to fix some old problems and work on things they wanted to improve a long time ago. Here are some feedback quotes:

#1

On its own, the idea is great and summarizes the essence of any modern social science since it gives freedom to choose your work, stimulates an individual's initiative, pro-activity and creative potential

#2

It inspires people to take ownership of our product. A good practice for freedom, responsibility, and trust.

#3

People feel more passionate and responsible about what they build, I guess. We finally have kind of deadlines, that we stick to. We have a clear definition of done for features, with clear deliverables such as product demo, blog post, working piece of software etc. It seems we deliver better quality, faster and more often.

Focus

Initiatives force you to focus on a single task. It improves timely delivery, but hurts mutual help. You might think twice to dedicate several hours of your time to help someone from another team. Sometimes it is good, but sometimes it can lead to local optimization. Sure, you will have your feature delivered on time, but from a company level your help may be extremely valuable.

I think this trade-off is OK. If you like to help other people, you can act in the Free Agent role rather than join an initiative. Or, you become more creative and try to teach people quickly instead of doing everything yourself.

Company alignment

This got worse. Ideas are quite diverse and I hoped to have an emergent vision as a result. I don't think it happened though. We indeed fixed several important problems, but some of the top problems are still there, like extremely poor notifications. I defined a wide goal to improve UX and increase NPS, but this goal was too broad and almost all features can be stretched to fit this goal. In my opinion, this lead to a slight feeling that our direction is unknown and the product has no vision.

Small Lesson #2: Define a bold goal for the year and quite narrow goals for the quarters.

And a quote:

The scope we do is driven by someone's desire but not by market demand. Sure, there is a filter which guarantees that useless feature won't pass. But this filter doesn't guarantee that necessary feature will go into development (because nobody would like to take them and HEADs cannot force). Important items can be in a backlog for years.

Initiative Reward

One of the worst decisions we've made is a reward for successful Initiative completion. Teams that complete an Initiative got several Orange Days (which can be converted to Days Off). This immediately downplays the contribution of all people outside Initiatives.

#1

Initiatives violate our core value: trust. A company should trust that their people will do their best to get a job done. Initiatives might give off the impression that "we don't trust you will do great work without a reward, so we give you a bonus that will stimulate you to complete work on time". It is assumed that development speed is low due to lack of deadlines, but in reality, complexity of integration and some external blockers are the cause.

#2

Some one still needs to do the "dirty jobs" and I don't think that it's fair that this work is not rewarded with orange time.

We wanted to stimulate the Initiatives practice with an additional reward, but it was a bad idea. In fact, freedom of choice and regular intrinsic motivation is enough to make great things.

Small Lesson #3: Don't underestimate intrinsic motivation.

Lack of Training

Another mistake we've made is poor guidance. Yes, I wrote about the practice, ran clarification sessions, and answered questions. But after this initial kickstart, I did a poor job of supporting and promoting it.

I should have worked with key people and ran educational session about how to define top problems, how to do UX, how to test results, etc. Self-organization requires good skills and great understanding of the business context. I relied on cheap self-organization, but this doesn't work in the complex environment of a B2B SaaS company.

Huge lesson #4: Adaptive self-organization demands high energy costs.

Overview

In general, people liked the idea, but implementation was far from perfect. Can this model replace traditional Product Managers and Product Owners? Yes, it can. However, make sure that you do the following to avoid our mistakes:

1. 20% of people should be highly experienced, have deep understanding of business context and good understanding of product development practices. If you don't have it, run training programs and maybe in a year people will be ready.
2. Education should not stop.
3. Information transparency is extremely important. You should have a process to collect requests from customers using various channels, aggregate their feedback and help people to distill top problems to focus on.
4. Be careful with bonuses and rewards. By default it is easier to not have them at all.
5. Implement freedom gradually.

#5 demands clarification. Imagine, you have a completely strict process where people got all assignments from managers. Here is an example of gradual freedom:

Choose own tasks from a story > Choose own stories from a backlog > Choose large features from backlog > Participate in backlog creation > Choose anything you believe is right.

If you jump to complete freedom from the typical Scrum practice of "Choose own stories from a backlog", people will feel frustration. Help them one step at a time.

Will we stick to Initiatives model?

I think we will go one step back and let people choose features from a backlog and participate in backlog creation, running required training programs for product development in parallel. With more experience we will restart the Initiatives practice. It is fun and works quite nice, but we were unprepared for it as a company, and I was unprepared for it as a leader.

Our new Service Desk application can be used to manage almost any kind of Request. One of its most common use cases is Idea Management, which allows you to gather feedback and prioritize features in your product based on your customers’ needs.

For the past several years, we’ve been using UserVoice for Idea Management. Now that our own Service Desk provides the same functionality and more, it’s time to move on. Last week we carefully moved about 10,000 users and 2,800 ideas to https://helpdesk.targetprocess.com to make sure your feedback is not lost.

This means that the forum at https://tp3.uservoice.com is now deprecated. You are welcome to share your ideas at https://helpdesk.targetprocess.com.

The other thing we want to highlight is that you can also use the Service Desk + Targetprocess combo to collect and manage ideas for your own projects. Service Desk has all the usual features such as voting and comments, it allows you to easily link ideas to particular work items in Targetprocess, and it’s free. Also, as our own Product Owner observed, it's much more convenient to manage incoming ideas when you have all the power of Targetprocess to back you up.

Service Desk can be enabled from the Settings page in Targetprocess. Take a look at our guide if you need help getting started, or send us a message at support@targetprocess.com.

In addition to all that, we have just released a widget that can be handy if you have your own system and don’t need the full Service Desk application, or if you just want users to submit requests without leaving your website.

We understand that you might need some flexibility from the default settings, so we made the widget customizable. You can hide elements like top requests, description, and attachments, define default request types and privacy, and change the form's subject text. It is already available for you and you can embed it anywhere – all you need to do is to provide a link to your Service Desk with the correspondent parameters. See our guide for more information.

Hello friends,

As 2016 draws to a close, we want to thank our users and all the members of the Targetprocess community for your continued support. We're on a mission to create the best visual management software possible, and we couldn't do it without you.

We're leaving 2016 with a clear purpose in mind, and looking forward to the challenges of next year with renewed vigor. Until then, let's all make sure we set aside a few moments to relax with friends and family.

And remember: every success, both great and small, is made up of hundreds of small steps. As long as you keep moving forward, you can create something beautiful. Best wishes for the holidays, and Happy New Year!

If you need a little more holiday cheer, check out our videos from previous years:
Seasons Greetings 2016
Seasons Greetings 2015
Seasons Greetings 2013