Building Your Product With Your Customers
“If I had asked people what they wanted, they would have said faster horses.” — Henry Ford
“If you hadn’t listened to people complaining about how slow horses are, you wouldn’t have invented the car.” — Henry Ford’s wife, probably
Everyone talks about agility today. Agile has been around for some years now, but somehow, it’s still a trend, and it’s still cool!
When you are building a startup, agility is crucial, but it is also easy. You are small, you don’t have legacy software, your customers are not trying to push the product in different directions, and you don’t have the pressure of keeping hundreds of employees that depend on you.
But what I’ve come to learn over the years is that agility is probably the main competitive differentiator and the biggest weapon any company — big or small — can use to stay on top of the game.
You see, I work at OutSystems, and I’m the product owner of our IDE. I joined the company when it was pretty much still a startup, and I’ve seen so much growth. We’ve reached hundreds of employees, thousands of customers, 1 billion dollar evaluation, and we’ve been strengthening our position as market leaders every year.
And although this is awesome, it also brings along a healthy dose of pressure to improve. With more customers demanding more and more features, we’ve defined that one of our key directions is to constantly become more agile, and deliver faster and better. So to keep our place as market leaders, we need to keep being innovative, disruptive, and agile.
Buckle up: We’re Going Faster
With this in mind, the first thing we did was isolate our IDE from the rest of the platform so that we could manage it as a smaller, faster startup-like product. Sometimes you need to invest in breaking monoliths so that you can evolve smaller pieces faster and independently.
This was not easy. We had to change the architecture of the product, break down several dependencies from the rest of the platform, and change the way we test the product so that we could test it independently. We even had to change the way we release and distribute the product.
With all of this internal work, we ended up doubling the number of releases and started releasing a new version every three weeks, aligned with our sprints. More importantly, we delivered 103 features more than the year before, meaning a lot of goodies for our developers.
Doing the Right Thing
But speed is not agility. Agility is how fast you can react to market changes and requests, or feedback from your users. It’s the combination of speed with another important thing: value. And value is delivering the right thing.
Agility is not simply delivering fast. It’s delivering the right thing fast!
Agility = Speed x Value
This is why we completely changed the way we work and collaborate with our developers — our customers — to better listen to their feedback and integrate it into the product:
1. Observations: First, we started by doing several interviews and observations of people using the product. We sat with experienced developers that have been using the platform for more than five years, and with people just trying out the product for the first time. This helped us get clarity on what concepts they understood and what concepts needed to be tweaked.
2. Surveys: Then, we added surveys. We basically asked our customers what they would change in our product, what they would improve, or what features they were missing. We had more than 100 developers reporting hundreds of improvements, new features, and annoying quirks.
3. Ideas: Another feedback source that was important to us was our community ideas. This is where our community spends their time helping us build a better product. To promote more engagement and activity, we revamped and improved the UI, created community badges, and we had 306 percent growth in the number of ideas submitted. We also created a simple yet powerful rule: No idea left behind. That means every time there is a new idea, we respond and explain if we will implement it or not. That way, we are transparent with our community.
4. Product Metrics: Finally, but equally important, we improved our anonymous and aggregated product metrics so that we could better understand how the product is being used. Collecting that data became an essential part of our process.
Defining and Measuring Success
Then, with all this context combined with fast deliveries, we were agile enough to start identifying the processes where our developers were spending most of their time. Once we found out, we worked on a way to quickly optimize them.
Yes, we focused on our developers’ productivity. After all, this is what low-code and OutSystems are all about!
So our focus became delivering features that would significantly reduce our developers’ development time. This would be a better success metric than simply delivering random features. More importantly, we decided that we would measure how every feature is contributing to this goal for success.
After all, it is part of our mission to make development faster for existing developers, too.
Have a look at the examples below.
Refactor logic accelerator; 4x faster, 20,000 usages in four months:
Quick find usages feature; 50x faster, 150,000 usages in two months:
New Application List and Recent Modules; 3x faster, 500,000 usages in three months:
Closing the Cycle and Giving Back to the Community
Our developers were becoming faster and faster; we were actively listening to their feedback and integrating it into the product. So yes, we could say we were hitting our success metrics, but more than that, it felt really good to deliver something so valuable.
Just in 2018, we implemented and released 16 of the top 22 most voted ideas in our community.
But collaboration is a two-way path, and we needed to close the cycle.
We had hundreds of people invest their time in giving us feedback on our product. We had 93 developers submit ideas that were actually implemented this year. We had experienced developers working with us daily! They helped test our features while they were still in beta versions and gave us more confidence in our product.
The recognition of this commitment was overdue, so we started mentioning our customers in our product release notes. Every time we deliver a feature or improvement based on someone’s feedback, their name will be highlighted.
Guess what? This leads to extremely happy and motivated developers in our community and strengthens our relationship with them, too.
Thinking Ahead: New Service Studio Beta
Working with your customers rather than for your customers really makes a difference and allows you to deliver a better product.
And we will keep working closer and closer with our community. By the end of the year, we will release our first public Beta version where any developer in the world can be an early adopter of new features and give us feedback on how to improve the product.
So the question is now, how can you work closer with your customers to build a better product?
