After 3 Years, Toolset Project Became Profitable
Today is the first day of 2015 and it’s a nice time to look back, see what we did in 2014 and plan for 2015. 2014 has been a great year for Toolset project, resulting in becoming profitable. How did this happen and what can we learn? Read on.
Right now, Toolset project includes:
- 6 developers – Bruce, Riccardo, Juan, Gen, Marcin, Francesco
- 4 supporters – Adriano, Caridad, Luo, Waqas
- 2 technical writers – Dario (tester / writer), Agnes
- 1 front-end developer – Kasia
- 7 plugins – Types, Views, CRED, Layouts, Access, WooCommerce Views, CRED Commerce
If we look back at the road to becoming profitable, I can see several milestones:
- Initial concept (July 2011) – we decided that making a living from one product (WPML) is risky and started Toolset project. At the time, two developers worked on Types. When Types was halfway ready, we also started developing Views.
- First release of Types (March 2012) – it took roughly 9 months to prepare the first release of Types. At that time, Views came out as a working beta. Views was available for free testing until being released as first commercial version.
- Views 1.0 released (May 2012) – When Views hit 1.0, it went commercial and we started selling it.
- Layouts is kicked off (September 2012) – we decide that the last missing piece of Toolset project is a drag-and-drop editor.
- CRED 1.0 released (November 2012) – We soon realized that many sites need strong front-end content editing. CRED addresses this need.
- Views 1.3 comes out with new GUI (Aug 2013) – the old GUI for Views was a result of features evolution. The new design looked at the purpose of Views and adjusted everything to be goal-oriented.
- First Layouts beta released (March 2014) – after a very long development cycle, we are ready with the first working version of Layouts. That version also goes to power own own site.
- Website redesign (Sep 2014) – finally, we reached a website concept that explains Toolset plugins properly. Shortly after this update, Toolset revenue exceeds costs.
So, what did we learn here?
Build Products that You Intend to Use Yourself
When we started Toolset, we had a rough concept of what people need. This concept was shaped mainly through our own personal experiences. Honestly, it’s better to have a rough and biased idea about what your clients may need, than have no idea at all. I would say, if you, yourself, don’t need a product, don’t build it. Leave it to someone else who has a first hand knowledge of the market and will ‘feel’ every good feature and every problem.
Be Realistic About Your Ability to Deliver
Once the product definition is ready, execution is everything. I have this video of Chris Lema about execution bookmarked and I go back to it from time to time. The best ideas are worth nothing if you cannot deliver. We overshot and went beyond our capability several times in Toolset project. This caused big delays and didn’t help us at all. If we had correctly realized what we can execute, we would have set more realistic goals and had delivered faster. Today Toolset team is big and strong and we can deliver much more. When we started, it would have been better to focus our energy on the most narrow set of features and execute quickly.
It’s Going to Take Time
Toolset is our third project. OnTheGoSystems started in 2007 with ICanLocalize. Then, we also started WPML. Guess how long it took for these two projects to get off the ground? 3 years. I wrote most of the code for ICanLocalize. As much as I wanted, it just took its time. Specing, coding, debugging, testing and doing QA all takes time. WPML’s timeline was very similar. It started at 2008 and become profitable at 2011.
Maybe it’s due to the fact that I was responsible for all three projects. Maybe someone else could start a project from scratch and reach critical mass in less time. My benchmark remains 3 years.
Besides waiting for 3 years, what other activities make a project fly?
Again, if we look at all our projects, we can identify trends and notice critical activities and features.
It Needs to Do Something Useful, Which People Understand
For WPML it was the easy translation controls, both when editing content and when managing the site.
For Toolset, it’s the ability to display custom content without programming in PHP.
Having features that people actually need and also that people realize they need is a must have. If it’s something really great, but that people don’t realize they need, you have a big problem, my friend.
It Needs to Be Usable
Our simple definition for usable is that people can do what they need with your products, without spending excessive time learning it. Every new tool will have a learning curve. Our job is to make that curve as easy-to-climb as possible.
You might have noticed, from our timeline, that most of 2013 and 2014 went to improving the usability of Toolset plugins. At the end of 2012, we already had most of the features working. It took another two years to make them also fun to use.
Today, I think that we’ve gotten a lot better at designing for usability. We run usability tests frequently and treat results with respect. We’ve learnt never to discard a usability problem, blaming it on ‘unqualified clients’. There’s no such thing. There’s just bad design.
It Needs to Be Stable
It’s pretty frustrating to go 95% of the way with a product, just to discover that you’re stuck on the remaining 5% due to an unfortunate bug. Takes all the fun out of using the product and reduces the chances you’d recommend that product to anyone else to zero.
Toolset support and development teams works together now, with excellent cooperation. This means that bugs are resolved quickly, fixes are delivered to clients as soon as they are ready (and not wait on the shelf for another few weeks) and everyone is happy.
Reaching this point wasn’t trivial. Building a strong team that focuses on client needs takes time and effort. I don’t see how this can be done instantly.
Products Need to Be Part of an Ecosystem
This is something that we’ve learned from everything we did. We develop WordPress plugins. Obviously, that plugin is going to work alongside other plugins and with a theme.
There is no such thing as “this problem is outside of our control because it’s coming from another plugin.”
You do this and you set yourself up for failure. Who cares what’s causing the problem? Clients need to know that you care about it and will do everything you can to resolve it. Even if this means you’re losing a bit in the process.
WPML team has 4 people working on compatibility. Of course, this doesn’t mean that we’ve covered everything, but we’re doing our very best.
In Toolset, we’ve made significant design changes so that our plugins work with every WordPress theme and with any other plugin. We’ve spent a huge amount of time on compatibility with WooCommerce, W3TC, SEO plugins and others.
Eventually, Clients Need Solutions, Not Products
Toolset plugins are ‘products’. However, the products are the means to an end. The ‘end’ is the solution. When a client buys Toolset, it’s to achieve something. It’s critically important to always know what your clients need and help them achieve their goals.
We run polls and surveys, but more importantly, everyone here is aware of what’s going on in our support. When clients are stuck with missing features, we first help with a quick workaround. Then, we put it into our features list. Eventually, these features make it into the products. Often, client-driven features are the best features we add.
We’re planning to do much more of this in 2015. We are already training new people to join Toolset support as ‘application engineers’. I’ll write more when this goes online.
What do you think? Want to share your experience developing and offering products?