There was a time when Project.co wasn’t called Project.co.
In fact, it didn’t really have a name at all. We just called it our ‘project management system.’ (I know. How imaginative!)
You see, we originally built it to manage projects for our sister brand, Wyzowl. Like a flashy, tailor-made suit, it was made just for us. To suit our specific dimensions as a business. To manage our projects, our way.
We knew it worked for us.
But how would other people want to use it?
What would they want?
Would the system really work for them?
Asking these questions – while continually encouraging, and listening to, the answers – has helped us evolve from the ‘minimum viable product’ v1.0 offering we launched with, to the much more nuanced product we have now.
In this article, I want to talk a little bit about how that development process has been guided not by our opinions – but by our users’ real-world needs – and why I think that’s been so effective.
We’ve implemented tools at each stage of the feedback lifecycle to help us understand more about what our customers want. We call it a cycle as the process of feedback, support and development is never complete. When we understand an area we can improve, plan it on our roadmap and implement it we then need to gather feedback on that development and start the process again.
The tools that help us do this are:
Feedback & support
In some ways, offering support and collecting feedback are two different functions.
But I think there can be a massive overlap between them…
Because, when people ask for help with something, that’s a type of feedback in its own right. It tells you something isn’t working as well as it could.
So, first things first, I wanted to make sure that it was super-easy and close to immediate for our users to contact us with problems and questions. We opted for live chat functionality, provided by Intercom.
This highly prominent button displays wherever users are in Project.co. They simply hit the ‘Chat’ icon and get an immediate form that allows them to start a conversation, search our knowledge base or submit a feature request.
This means people can get in touch with us in a way that isn’t onerous or difficult.
From a support point of view, it ensures we can help struggling users as quickly and immediately as possible.
But in a feedback/product roadmap sense, there are other benefits, too. Intercom comes with some really nice features that help us in a variety of ways.
We use tagging to put people into ‘buckets’ – so, if people request a particular feature update, we can use tags to measure how many people have made a similar request. Or, if people have provided a testimonial, we can track that as well. Tagging helps us keep track of groups of people by manually adding a tag to their record.
We also use segments to categorise users. This is done based on attributes – data points like sign-up date, how many times they’ve logged in, their account role, how many projects their account has, how many internal/external users, and other characteristics. This is an automatic process which is done by Intercom. People can enter segments and leave segments automatically.
It all helps us to group and analyse information about how people are using the system and how we can best support them. We can then communicate with groups of people in the most relevant way possible.
Using live chat also allows us to have a two-way communication with people; to ask questions that help unpack why they were asking the questions they were asking, so we can understand – underneath the surface – what they’re looking to achieve.
When we receive messages from live chat, we often point people towards our feature request page.
This page – powered by Canny – doesn’t just allow people to submit their own requests. It also allows people to comment and upvote ideas. This, in a way, builds a sense of community around a product. And, more to the point, means that we can gauge how many people are likely to actually be interested in a particular feature update.
Suddenly, we were able to make decisions based on delivering maximum impact to our user base, rather than working with our own gut feelings.
It’s also extremely interesting to get feedback from people on the feature requests other people post. We’ve found that someone might post a feature but then the discussion that happens around that feature helps us plan how the functionality might work based on feedback from the crowd.
Canny is an easy tool to use, and we genuinely recommend it. It’s great for gathering insight around the features that matter most to your audience, stimulating discussion and debate that leads to real insights.
Ultimately, the ideas that are the most universally popular (or the simple ‘no-brainers’!) – are the ones we add on to our roadmap.
Whenever we change the status of an item within canny – say, from ‘planned’ to ‘in progress’ – people who’ve commented or upvoted on that idea are automatically notified via email.
This is important as it helps demonstrate that peoples’ opinions are genuinely being heard and acted upon. I think it has helped develop a sense of ownership among our userbase – that their input is helping to build a system that works hard for them.
There are other upsides too – one, it helps bring people back to the product. People who had struggled to perform a certain task or manage a project a certain way suddenly found that their problem had been solved. Treating feedback in this way helps optimise retention and engagement.
The other, slightly surprising upside, is that it actually plays a role in helping us drive sales. People were able to make an informed decision about Project.co, based not only on what the system could do right there and then, but also on the exciting features we had in the pipeline – and the fact that we were inviting a great deal of input from users, and responding to this feedback in our development roadmap.
It all helps send out a message that we’re a team that listens and responds – building a sense of trust that I’m sure helps us persuade people to take the leap and use Project.co!
The result: a great feedback loop!
The result of all this is that we’ve developed a fantastic feedback loop that works from end to end, and delivers for both ourselves and our users.
We have that initial live chat and conversation – which helps us understand common threads.
Then we have the feature requests page which lets us gauge from a sizeable group of people whether an idea is actually popular, and how many people it will actually benefit.
And finally, we have the communication from us back to those users, letting them know that their feedback has been actioned and their feature has been built and added.
These emails go out to our whole mailing list. They don’t just talk about what’s been added in this update. They also talk about ‘What’s next?’ as you can see at the bottom of the email.
This all leads to more engaged users – and it helps us make decisions to advance our product based on what’s really important to the people who actually use it. It also encourages others who’d like to see a change or new feature to get in touch. When you can see that other people are having their feedback acted upon, you might be more likely to share your own thoughts, too.
One of the quickest ways to frustrate users of a SaaS tool is to force your way of working onto them.
From the beginning, I was determined that Project.co wouldn’t be like that. I wanted it to be adaptable to the different ways people wanted to use it. I’d argue this is even more important, because of the way the tool was built – to serve the needs of our particular business.
Treating feedback in this way, and letting it drive our product roadmap, is the best possible way to ‘leave our ego at the door.’ It gives us the best possible chance of learning from our users – rather than preaching to them – so, over time, we can develop a product that serves them in the best possible way.
And, by encouraging volume in our feedback, we’ve very much been able to make measured, sensible decisions around development.
Fancy joining in? Create your own free account today!