How the backlog issues prioritization saved the company from closure during the pandemic. Stories of launching three products. Part 2

The underestimated path to product-market fit, or where organic growth comes from

What did you decide to do next?

It was March 16, 2020. I rushed to the States to be closer to the NY cluster of the event industry, so when the quarantine is over, I can resume negotiations ASAP.

While awaiting my flight at the empty airport, I wrote an article about Ducalis, our internal tool for issue prioritization.

The plan was just to drop the article to my Facebook friends, set up a simple landing page with an email capture form and see the reaction. I thought, well, if we get five emails, maybe we could start paying more attention to the product and try to promote it.

Using Google Forms, I hastily assembled a landing page for demo requests as the service wasn’t accessible beyond our corporate network. On Wednesday, March 18, I published a post on my Medium and Facebook pages, and the next day in the Russian startup community at vc.ru.

Did you manage to get five emails?

The results of the announcement were stunning.

In the first week, we got 160 requests for demos. The feedback from customer interviews was overwhelmingly positive. Product managers and scrum-masters started recommending Ducalis to each other. Even several Agile communities shared the link for free and without us requesting

The team spent tens of hours talking to the first clients from banks, famous startups, one of the largest car manufacturers in the world, and even a product manager from Atlassian itself (the developers of Jira).

One of Atlassian communities reached us out to run a webinar about Ducalis and our story about prioritization struggles. There were 92 attendees.
In one week, our company moved from a near-death experience to a super active growth phase with a product around a huge pressure point — issues prioritizations and team synchronization.

How was the experience of launching Ducalis different from your previous products?

Great question, because we will have to compare completely different experiences and markets, but let’s try to classify together.

What does it do?

Concert With Me: Ticket eCommerce selling exactly the same secondary tickets as everyone else.

Tendee: A combination of methods for promoting events, and the tools that we have developed for these tasks.

Ducalis: A service that quickly prioritizes and synchronizes product team goals on Jira.

Why did it come into being?

Concert With Me: Wanted to create an international eCommerce platform.

Tendee: Used the skills, connections and industry promotion tools developed at Concert With Me.

Ducalis: Solved the internal problem of issue prioritization.

The main advantage

Concert With Me: Cheap traffic acquisition from a channel that no one in the industry has ever noticed.

Tendee: “All-in-One” for digital event marketing.

Ducalis: Faster, simpler and more reliable than Jira plug-ins, individual complex services, Google spreadsheets.

Main reason for growth

Concert With Me: Found a “hack” in Facebook promotion.

Tendee: Flying to different parts of the world for meetings, acquaintances, conferences, and subsequent sales.

Ducalis: A personal story of solving a problem that has resonated with a lot of people.

Most popular customer response to product

Concert With Me: “Why are the tickets so expensive? When will artist X come to town Y?”

Tendee: “Who exactly are you already working with? What are they saying?”

Ducalis: “We have exactly the same problem with the prioritization of tasks! And how did you solve X?”

Let’s take a look at launching on different markets then, shall we?

Generally speaking, the first two products grew mainly because we had built efficient distribution channels:

Concert With Me existed in a very competitive market and its added value was minimal. It was a success because we found a marketing channel that others had missed.

Tendee had great added value for customers, but it solved a problem that the customers were not consciously aware of. Therefore, it required direct sales, and a very long onboarding process through the agency model, where we showed the value of the product in solving the customer’s immediate needs.

With Ducalis, everything turned upside down.

We found an effective solution to one of our own problems, honestly proved the value to ourselves, and only after that, we shared the product’s story with other people. This resonated, and organic growth started without any investment in marketing.

Comparing the experience of launching Ducalis to past products allowed you to realize a number of thoughts that you once read in a book by Des Traynor from Intercom, but hadn’t fully understood at the time. Tell me about it.

Two years ago, I was reading Intercom On Marketing, a book by Des Traynor and Matt Hodges. Traynor and Hodges began their book by asserting that when you put a product on the market, you have to write stories and tell them to people, an advice that perplexed me at first:

“No matter how good your product is, if you can’t tell a cohesive, compelling story about it, you’re going to have a very hard time getting people’s attention when you actually do take it to market.

“For decades software was sold using feature-based marketing: But SaaS has changed that. A lot of startups spend untold time and resources cooking up some fancy marketing matrix when in fact you just need to have lots of real-life conversations with like-minded people about their problems.”

I was reading a book about marketing by a founder of a very successful company worth over a billion dollars, and I couldn’t wrap my head around what he was talking about. So, where are the secrets of Google AdWords? What about email marketing segmentation? Why is there no chapter on Facebook Ads optimization? Which remarketing service should I use? Etc.

But now I realize that due to the specifics of my experience and the markets I had worked in, I previously perceived product promotion in a strict sense of being a process of traffic acquisition, setting up analytics, collecting emails, retargeting, direct sales, and so on.

Finally, with the experience of Ducalis, I grasped the notion about products that start from a real pain. It’s hard to figure it out in theory — one can only experience it. Our team was lucky enough to stumble upon an undiscovered acute problem and find an effective solution for it.

The stories behind Basecamp, Intercom, and Slack began the same way. The real challenge triggered the founder’s sharp pain, not the friend’s words: “Cool stuff! Well, I’d definitely buy it!” A sincere honest desire to tackle one’s own problem was the key to creating high added value, and as a result, to organic growth.

The real-life story of solving one’s own problem drastically affects product marketing. You have something to tell, and you know the exact pressure points to push. People don’t click on the ad because it’s somehow specially set up. They click if an ad message resonates with their personal problems.

They say you’re not an indication, and you shouldn’t rely on your needs. To me, that’s exactly what you should focus on, especially in the early stages of product development. When I worked on games, I noticed that they showed the best results if people in the company were eager to play the games themselves, which also provided vital immediate feedback. Ducalis solved your own problem, too. Tell me how you came up with the product.

At some point in our work on Tendee, our Jira backlog was overgrown with an endless list of ideas that anyone could record there.

Everyone in the team saw the truth in their own way, so the tasks were undertaken randomly. We broke everything from your advice: “Why saying ‘no’ is important for product development”.

From Product Strategy is About Saying No — Des Traynor — Business of Software

We decided to rethink the issue prioritization in the company. After reviewing some of the systems, we settled on a hybrid of RICE and AARRR, with different weights for each criterion (below in parentheses).

A product manager had to evaluate issues by the following criteria:

• Sales. Helps with Sales. (1)
• Activation. Shows the benefits of the product. (1)
• Retention. Returns users to the product. (1)
• Service. Reduces customer support costs. (1)
• Fb Ads. Gets us closer to being a Facebook Marketing Partner. (1)
• Mass. How many customers, events or money it affects. (1)

A developer had to evaluate issues by the following criteria:

• Time. Time spent on development / Complexity. (-3)
• Value. Importance for development and product. (2)

You immediately developed your own service to automate this task?

No. We quickly connected Google Sheets, Automate.io, and Jira Cloud to automate this workflow, but this Frankenstein only worked for a couple of months. And then everything fell apart.

The main problems and pains were as follows:

• Google Sheets was overgrown with old tasks.
• There were lots of duplicates due to synchronization errors.
• We had to open a gazillion tabs to read each issue description and understand the context.
• Coworkers evaluated issues on different weekdays. Sometimes someone just forgot to evaluate them. It became too difficult to coordinate top priorities.
• It was impossible to update the spreadsheet (add/remove criteria or teammate).
• It didn’t allow us to reevaluate old issues. Some scores became outdated as our team’s priorities evolved.

We did want to solve the problem of issue prioritization, and even rigged a solution and integrated it into our processes, but it didn’t work for technical reasons.

So then, understanding all the details of the process, you decided to make an internal tool to ease the pain?

Yes, our developers offered to design our own internal solution. They made it in their spare time as a residual, and the first version appeared after a couple of months. We were sure that it would be an internal soft just for us and chose a gag name Ducalis because of the memes.

Since we devoted all the time to our main product, Ducalis only had the important features we could best use in our workflow. Eventually, there was nothing extra in the tool due to this ascetic approach.

We evaluated ideas for the development of Ducalis using the tool itself. We chose the criteria based on our prioritization experience with Google Sheets. Thus there were: UI speed, context availability, frequency of use, collaboration, development time. We made the product for ourselves, so we got a blazing fast UI, handy reminders in Slack, full issue context at our fingertips, and all the necessary hints about criteria. It tackled our problem brilliantly.

How exactly did you know that the product was solving the problem?

The team was actively using Ducalis for weekly assessments, and this had notable benefits in combating the prioritization problem:

• It started to take 15 minutes a week to assign scores. The system worked like a clock, and everyone was trained to evaluate their issues weekly.
• The Friday ritual of issues reading by all team members was born. We had a much better understanding of the general scopes of tasks and groomed the backlog every week. Google Sheets could not sync us unless we manually pinged each other.
• Scores were discarded monthly, and outdated issues were to be assessed again. Often we would simply delete them. Expiring scores cured the problem of “soul searching,” which again was impossible in Google Spreadsheets.
• This process generated many “productive conflicts.” People started asking questions like “What kind of task is that?” “Why would you do that?” “I don’t understand the description,” “It doesn’t seem to matter.” They provided feedback and respectfully disagreed with each other, which led to better priority negotiations.
• The team also began to discuss the criteria themselves, thinking about how one or another part of the system affects the success of the entire product and company.
• Product managers and salespeople began to understand the importance of code refactoring issues, and developers realized why the make-up of the helpdesk is so important.
• It even became a small game. Ducalis regularly awarded progress by posting who had “nailed it” on the Slack channel. Public appreciation from the heartless machine also worked great. That’s why the teammates tried to evaluate the issues on time, and got upset when they couldn’t.

That is, Ducalis has changed your prioritization process and made your team more efficient. At that point, did you realize that you’d created something valuable?

We had no go-to-market plans for Ducalis. All we wanted to do was clean up our planning and prioritization chaos.

It never occurred to us that this product could be useful to other teams outside our organization.

There were so many hotshot articles, advice, and conference talks about the right product strategies, prioritization approaches, and roadmap formations that it seemed we were the last company that was tackling the issue prioritization problem.

When the event industry slipped into a coma because of the coronavirus, the first reflex was “Let’s turn the product towards online events.”

However, it implied a completely different marketing strategy, and Tendee wasn’t ready for it.

At the same time, I was reading the news about the increase of Zoom users and was envious of the services that are fully online. As silly as that sounds, I thought, “What if I serve Ducalis as a tool for remote teams?”

And I was surprised myself that we didn’t have to “invent” anything. We’ve been a remote team for several years, and with the help of Ducalis, we’ve learned how to synchronize different points of view on features and priorities in product development.

I didn’t even tell any of my colleagues about the plan. I just decided to write an article and see if we get at least five emails from the submission form. And you already know how it went from there.

When the product targets a specific problem so precisely, a huge number of feature requests and ideas come in (feature creep), and dark forces begin to pull the project in all directions. How do you deal with it? What are your key criteria for the development of Ducalis now?

Having finally understood Des Traynor’s covenants, we now have two main tasks:

• Listen to as many stories, problems, and pain points about prioritization as possible. Don’t try to persuade anybody to use our product, but turn on active listening and empathy to understand the customers’ processes, pain points, and solutions.
• Find the segment with the best match between our solution and their pain. Decide what we can do better for them, and understand how much they are willing to pay for it.

So far, based on the results of the first few dozens of in-depth interviews, it has become clear that the needs of the corporate segment should be studied in more detail. To close deals with large customers the product must be further developed towards security, access control, encryption, and work in corporate networks.

At the same time, we continue to focus on factors that we’ve identified based on our experience with spreadsheets. We have also already validated that they all resonate well with our clients:

• Speed: The issue evaluation process is extremely slow when each issue is opened in a separate tab. We want to spend as little time as possible on the issue evaluation process.
• Retention: We send notifications to Slack solely, and that’s a really important way to make a team evaluate issues constantly.
• Collaboration: The key task of the tool is to give an overall picture to the whole team, to synchronize the vision, to start crucial discussions at the right moment (before development).
• Self-Service: Make the UI intuitive, write help articles, suggest how and what is better to configure, which criteria to choose.

All this has been transformed into our criteria for issues prioritization in Ducalis for the further development of the product.

And one last question. How would you summarize your key takeaways from the story so far — and clearly, it is still in its beginning?

As usual, it’s more sophisticated than “one main idea.”

Mega-platforms are not your friends — but neither are they your enemies. We live in the age of mega-platforms that have monopolized certain market segments: search, communication, social networking, video, etc. It is almost impossible not to depend on them, but it is fundamental to be able to diversify the risk. Design your product to integrate with platforms while considering that it may no longer exist at some point in time. Bad strategy: Concert With Me’s full dependency on Facebook. Good strategy: Zapier diverse strategy.

Focus on the added value of the product, on how you solve people’s problems, not on bugs, features, and other attributes. Tendee’s customers complained about every little bug, and several times it was why they stopped using our product (a post wasn’t published, metrics weren’t updated). On Ducalis calls, clients asked me a couple of times to stop apologizing for tiny bugs. They say they understand everything and believe we will fix it. Every tool has bugs, but if the product truly treats the pain, it won’t be the reason they’re leaving.

Don’t take feedback at face value. Develop empathy and try to understand the issues and real motivation of your customers. Listen actively and develop empathy. Don’t promise the moon. Don’t try to persuade someone they are wrong. Think about the reasons why they ask for something, try to understand what problems they want to solve (and things they don’t want to touch). Listen to as many stories as possible. The team and I have recorded dozens of calls, and we listen to them again every now and then to collect stories and problems.

An honest story of solving the real problem is better than a list of cool features. Every single customer has said that this or that idea from the announcement-blogspot resonated deep. Nobody said: “Yeah, that’s a nice feature.” Our real and detailed history of solving the problem replaced the feedback of the first clients (that didn’t exist) and became our best landing page, salesman, and marketer.

Conclusion

If you also have problems prioritizing tasks, I would be genuinely happy if you could share your stories with us. Text us in the chat at Ducalis.io.

Thank you for reading my story. And thank you, Oleg, for the opportunity to tell our story to the best minds. If you want to share your opinion on why things happened as they did, leave a note in the comments section. We’d be delighted to hear your story.

P.S. If you want to learn how data can help you build and grow products, take a look at Simulator by GoPractice!