Happy Monday everyone!
Today we have two new stories for you:
1. How Quipu kept churn rates under one percent ever since their launch
2. User Research on the Human Body for New Users
Have a great week!
How Quipu kept churn rates under one percent ever since their launch
Going into its fourth year, one of the things the Quipu team and its CEO Roger Dobaño are proud of is their low churn rate.
Quipu is an online billing software that solves your daily administrative tasks. And as with any SaaS product, churn is a number they keep close track on, says Dobaño:
I’m in touch with the churn numbers daily, but we measure it monthly, like most startups.
A low churn percentage is not only validating that they’ve built a product people like, but keeping the rate down over years has also taught them a lot about how their customers think and act, according to the CEO:
For a B2B SaaS company, it’s often quite expensive to acquire new users, so we’re very proud that we’ve been able to hold churn under one percent from the start.
Support
It’s not rocket science, with more customers come more responsibilities, and that means a higher demand for service.
As you’re scaling your customer base, one of the most important things you need to do is to make sure your customer service team scales together with your customers. The easiest way to keep churn down, is to have someone that really understands the product and cares about the customers.
He continues:
Even though many of your customers never need any help with the product, it’s part of the trust relationship you build, as the customers know that there are humans to talk to at the other end of the software.
The first 12 months Quipu didn’t hire customer care people says the CEO:
For the first year of our business, I did all the customer support myself. Not only because the team was small, but so that I always knew what our customers thought about our product.
He says he’s still in touch with the customer service team, as it’s one of the best ways to know how to develop and improve the product.
He explains that the way customer service agents should attend struggling users could be an article in itself. The baseline is to listen a lot, be understanding, patient and get to the core of what kind of problem the user is facing. There’s usually always a way to fix it.
No automated unsubscribe button
It’s not about making it hard for customers to unsubscribe, according to Roger, but it’s about understanding why they want to leave.
If you want to unsubscribe, we’ll get notified when you push the button, and we’ll get in touch. Their reason for unsubscribing is often connected to a task we can help them achieve very easily, preventing them from leaving and making them happy again.
And if the customer has decided to leave anyway, you’ll at least have the data on why, if you actually talk to them. It’s also for security reasons, as people’s financial data has to be treated carefully.
When you’ve grown a significant amount of customers or users you should also consider measuring CSAT and NPS metrics.
- Also read: How To Improve Your Customer Satisfaction Score and Net Promoter Score
Apart from great service, upselling is another way to prevent customers from choosing another product. The more ways people use your product, the lesser is the chance of the person leaving you.
With a very low churn rate, you’re actually able to reach negative churn, if you’re able to upsell enough.
Track patterns
When you have a payback period of one year, which is normal in SaaS companies, you need to know that people are happy especially in the beginning to keep the retention rate high.
Apart from speaking with the customers, tracking their movements and tasks inside the product is a very good way of seeing where it goes right and wrong.
For example, in Quipu one of our services is managing invoices. After looking at the user movements, we now know that the retention rate is much higher if the user creates three or more invoices. With this info we’ve been able to retain more customers over the years.
Dobaño adds that it’s also important to use movement trackers to contact users who are struggling, even before they complain or think about leaving.
Don’t go crazy with features
It’s both upsides and downsides to talking a lot with your customers (obviously more positive sides though). One of the challenges is that people have a lot of thoughts on what kind of features you should develop next.
If you’re working B2B, you’re in touch with professionals, and they’re aware of what type of features would make their day easier.
This results in new features that both keep the retention rate high and make it easier to acquire new users.
But it is easy to take water over your head and create ten good features to please everyone, instead of making 3 perfect features. It’s a difficult balance, according to Roger:
We try to focus 60 percent of our capacity on building our existing product better, and 40 percent of our time making features for acquiring new customers.
The holy two percent
When you’re working with high growth products, it’s often essential to be raising funding from investors.
A motivation in keeping your churn low is that most investors will not bet on a SaaS startup if it has a churn rate of 2 percent or more.
So even though you’re acquiring a lot of customers early on, having churn in mind from the first minute, can be more valuable than you think.
Some last tips on the list to prevent churn you should consider is:
- Make meaningful partnerships with complimentary services.
- Don’t let credit cards expire.
- Let the whole team know your churn rate and be aware of changes
Better code structure: working with pods
Usually we organize our javascript apps either by what they are or by what they do. The first is like rails: separate directories like components, containers, reducers, etc. And the second more or less like feature/DDD: user, cart, and so on. Tho both of these options are very mainstream and solid they contain some constraints.
When you structure the code files tree by what they are you tend to keep every component of the same feature so distant that it’s very difficult to connect the pieces. Therefore you dive into some troubles like the path hell; a lot of require('../../../etc') in your code. And everything is extremely coupled to the directory structure.
In the other hand, when you are driven by what they do everything is more isolated and maintainable. But there’s a lot of duplication. And the communication between the features either is based on a weak contract or depends upon some infrastructure. Both of these options are prone to raise some bugs.
Pods it’s an evolution of the last one. You can think about pods like the microservices of the front applications. A pod is an isolated and completely independent microapp which can communicate 100% with other pods. Therefore, you get code base which is composable, extendable, reusableand extremely easy to test. Tho, the main benefit is that you completely erase the inter components side effects. Once a pod is failing you are totally sure that it’s because itself has something wrong; not an external piece.
A pod is an isolated and completely independent microapp which can communicate 100% with other pods
The unique requirement of the pods is to driven all the pods intercommunication through an event bus. If you’re already using any Flux pattern, lib or framework it’s gonna be very easy to lead this communication to the dispatcher; which is actually a single point for the events.
For a pod is not mandatory to have the logic, presentational and communication layers. Can have all of just one of them. Imagine a router pod. It has the logic and communication layer but doesn’t expose any view. Or the opposite, a form pod which only exposes a presentational layer and depends 100% on the arguments received (see React props).
Because every pod acts like and independent application we place the tests inside them. This means two things: stop duplicating the files tree, and making code coverage meaningful. When you have 100% coverage with a pod you know that it won’t fail. No side effects.
In a nutshell, by working with pods you get a secure and very flexible structure. Very easy to test and without side effects. It scales from 0 to millions without worrying about big refactors due to the fact that every pod is isolated but available to communicate with all the other pods.
In case you want to see some code here’s a Github repository with a simple pod architecture. Give it a look and check the benefits the pods can offer. If you have some doubts or proposals don’t hesitate to open an issue or comment here. This is a living pattern. We’re using the pods at Ulabox and they’re proving to be the solution to a lot of structural codebase problems. Tho, we’re willing to listen about your thoughts and concerns.
The journey is long, take some pods.
User Research on the Human Body for New Users
Hi! Thanks for agreeing to chat with me now that you’ve had your human body for a couple weeks. I’m excited to hear about how things have been going. Here’s how I’d like to spend our time: we will have an open conversation and explore your experiences. Later on, I have some specific questions that I would like you to answer, to get more specific feedback. At last, I’ll be sure to leave enough time at the end for any questions I might be able to help you with.
Does that sound good?
— Sure, sounds good.
Awesome. So is there anything you’ve noticed that you particularly like about your new body?
— Well, I like these sausagy things, but there’s one that is too short and out of the way, I wish they were all the same length and pointing in the same direction.
I’m going to assume you’re talking about your fingers. The little one is called “thumb”. Has it been useful in any way?
— Not really.
What if you want to grab something?
— I don’t see a problem. I have more sausagy things.
That’s true. Anything else about the fingers that you’d like to share?
— Let me think. Five sounds like too much, no? Maybe two or three would be enough.
Were there any particular situations where those extra couple of fingers were in the way?
— Yeah I was in bed with a friend…
That’s enough. Thank you. Any other aspects of your body you’ve particularly enjoyed or liked over the past couple of weeks?
— As I was saying, I was in bed…
GOT IT. Let’s move on. Have there been any events or situations where you’ve found your new body limiting?
— Yes I tried to fly from a tree branch and realized quickly that I couldn’t fly.
How did you reach that realization?
— I fell. Straight to the ground, landed on my arm. Which also made me realize these arm things aren’t very good at taking impact, the bones are pretty weak. I had to see someone called a “doc” and now I have this cast thing on. Are you going to fix that?
Oh my! I’m sorry to hear that happened. I’ll take a note to make sure we cover that type of bug in the design for later versions. How does the cast change things for you as you evaluate your body?
— I can decorate it with doodles. I really like that. If I do it on the outer layer of the body it wears off. Are you going to make cases for the body? Like with flowers and stuff. I saw some people wearing them.
You mean clothes? Sir, are you walking around naked?
— What are clothes?
Never mind. Let me ask you something. How has the temperature regulation been in the new body?
— Hmmm… what’s that word…? Cold! Yeah, that’s it! This body doesn’t have enough fur. Except in some funny parts, where it shouldn’t. You should definitely review the fur.
Interesting… I’d like to switch gears a little to focus on keeping the body up and running. In your orientation, we went over things like eating and grooming. Is there anything noteworthy you’d like to share about those kinds of processes?
— Eating is good. I like that. But I felt it was a bit random. There were no clear instructions on what I should or shouldn’t eat. I enjoyed the sweet things. I don’t really know why you offer green stuff with no taste.
Vegetables?
— Whatever you call it. The red stuff was good, like tomatoes sometimes, when they came with cheese, in a bun, with bacon, and meat.
Burgers?
— YES! Those were really good. I basically just ate those.
Welcome to America.
— What?
Nothing. Thank you so much! That’s all for regarding that subject. I just have a few more questions. On a scale from 1–5, where 1 is “I wish I had my old self back” and 5 is “I can’t believe I didn’t get this body sooner”:
— Not having a body is very different, you can do a lot of stuff if you have a nice working body I guess. I’ll say 4.
How would you rate your satisfaction level with your new body so far?
— 2. Maybe 3 on a good day.
Is there anything in particular that lead you to answer that way?
— It’s kind of slow and fragile. I wish it was faster. And bigger too.
How likely are you to recommend this experience to a friend?
— 3.
Is there anything in particular that lead you to answer that way?
— It’s fun to use for a while. But I guess you might get tired of it after a while, and would like to change it for a newer, faster, better-looking model.
Right on the spot. And finally, what’s one thing you really hope will be added to your body in the future?
— Wings. Or wheels. Whatever makes it faster. And fur. I said fur before, didn’t I?
You did. What value would that addition provide to you?
— I want to be faster. And warmer.
Thanks again for all your feedback — you’ll receive the gift certificate to the new body maintenance shop shortly. I’ll talk to you again in a few weeks. Take care!
What I’ve learned from organising 25 tech/startup events in 4 months
When I started working at itnig this fall I knew I would arrange events, but I couldn’t imagine that I would host 25 tech events in 4 short months .
I’ve learned a couple of things along the way, that makes me certain the next 6 months of tech events at itnig will be even better!
At itnig we do events for several reasons:
- We like having smart (speakers & attendants) people at our place.
- We care about the Barcelona tech community, and want to contribute to its growth and quality.
- We want to show off itnig and our startups .
Speakers
The topic of your event can be super relevant, trendy or interesting, but if the speaker doesn’t have a “name” known in the community or work in a known company, you’re screwed. It’s the cold, harsh truth. I personally thought that if you have a topic that’s interesting, presented by someone with experience and merit, it would be enough, but it usually isn’t.
So if your goal is to attract a decent number of people to your event, you need to find a great topic AND a great (+known/semi famous) speaker.
However, don’t invite speakers that aren’t eager to share! You can always manage to convince someone really great to come present her/his experience, but if you have to struggle to convince them, or if you notice the speaker only attends because of having a hidden agenda (usually hiring) it could be reflected through the presentation. Make sure the speaker actually is looking forward to the event.
Also, if possible, try to book a speaker that hasn’t recently been around talking at other events in your city. You want the name to sound a bit exclusive. If you find it hard to find good speakers, don’t be afraid to find speakers internally, especially if you work in a well known startup or company, sometimes the best speaker sits just under your nose.
It’s not vital, but if you can, ask the speaker to stay behind after the event to chat and have a few drinks with the attendants, that’s always a huge plus, and makes the whole event experience much better.
Topics
How you choose your topic relates a lot to what your motivation is, what kind of community you have, and how big the startup ecosystem around you are.
One of the keys for me who’s hosting the events, has been to actively talk to our developers, marketers and product managers on what kind of topics they find interesting, or what new things they want to learn. This only works if your team actually follows trends and stays up-to-date with what’s happening in their field of expertise.
Apart from this I try to get feedback from our community and of course follow thought leaders through social media and newsletters.
Make sure the topic has not been done by anyone else in the community, and if someone’s covered it, make sure you’re bringing something to the table. Tech is moving fast, nobody cares for hearing something twice.
No matter how interesting your topic is, try to always stay under 45 minutes. It’s just as important to open up to questions from the audience, than to lecture from the stage.
Attendants
So I’ve covered topics and speakers – two essential parts of every event, now over to the last ingredient — the people.
Refreshments (beer) is key. Or to put it more accurately, beer is the oxygen people breath at events, i.e an event without beer is like holding an event in space. Only very weird people that are super interested will show up.
And even though these super interested weird people are great assets in all communities, you really need to appeal to the broader mass as well, if you want to build a diverse community.
To get people inside your events you’ll have to use an event-platform for announcing, informing and sign-ups. If you don’t have a big social media following, make sure your friends in the community help you spread the word.
We use Meetup which is great for certain things, but in some ways it’s a bit broken. With that I mean that most people that cares about tech (at least in Barcelona) are using Meetup and you can build a big community on the platform, but many people have little or no will to commit to events they press attend to.
This is an issue I’ve been talking with a lot of people about, and it seems like people are using meetup more like a calendar of events they are thinking about attending, and not something they’re definitely doing.
The best way to ensure that people are showing up, and not only pushing attend is to take a small symbolic fee (1–2 euros).
So, there you have it, hope to see you at the next itnig event! If you have a topic you think we should cover in 2017, let me know!