Quentin de Chivré has a particular set of skills, skills that he honed over years of building successful products. And his ability as a “tech grower” extends beyond pure tech knowledge and towards steering organisations into building great products.
As the first lead developer joining PriceMinister in 2000, he helped expand the team from 4 developers to 30 team members over a 9 years span. He then moved on to creating Shopmium, a digital couponing company successfully acquired by Quotient Technology Inc. in 2015. After his startup had been bought by Quotient, he continued growing the engineering department, which has now doubled.
In this interview, Quentin de Chivré shares his experiences and tackles the specific complexities of building a product in a startup context. Focusing on resources and output, the two general dimensions he deems the most important to take into consideration as a CTO, he outlines the practical steps to address each of them. Any startup company looking to take a break from day-to-day struggles will benefit from his take-a-step-back guidance.
Think twice about what your people focus on, they’re your scarcest resource.
1) Reduce the number of languages your team deals with
How do you make do and create added value when resources are scarce? How do you achieve much with little at hand? This is the all-too-common challenge encountered by startups, and Shopmium was no exception.
Using Titanium was a growth hack which lasted some time for Shopmium, as it allowed them to focus on one language instead of two at a time. And it’s only half-way between the first and second funding rounds that the tech team became specialized and split in two pods, one for mobile apps and one for servers, allowing developers specialization. Now that their apps are native they are moving towards an API philosophy, with a server and API serving 3 clients, Android, iOS, and web.
2) Let your people focus on your core company know-how
During startup beginnings financing is scarce and an engineer salary is a huge cost. “Still today, my infrastructure costs are quite low compared to an engineer salary” adds Quentin. He goes on to explain that whereas prices for machines decrease over time, prices for skills are stable or even on the rise. So the trade-off between technology, machines and developers is really about productivity and maximising what your team can build.
“Adding machines is clearly less costly than adding engineers. Developers are thus your scarcest and most expensive resource. The need to outsource everything possible is major, focusing your few resources on your core business is what’s important.”
“You have to take the time to really understand what is your core business and what is not, and then trim down all the tasks that bring less value to your product than the others”, says Quentin. “Once you’ve found competency, it’s all about maximising their productivity and efficiency. This is why I chose to work with Ruby on Rails, and not Java. I know there’s an ongoing debate about Java and Ruby, pointing out that Ruby is less effective. But Ruby is extremely interactive and iterative, and so we chose Ruby. Once again, adding machines is less costly than adding engineers.” The core of Shopmium’s added value was not in its infrastructure, nor was it in its logging or project management capabilities.
“It’s the same as buying a flat, renting it or staying at a hotel. Today, I’m staying at a hotel. It seems more costly than staying at a furnished rental… But I do not have to do the housekeeping or pay for the housecleaning. So in the end, and considering the cost of an engineer, the overall cost for the tech team is much lower.”
With this idea in mind Quentin chose to work with Heroku. With first-hand experience of how long it can take to add machines, going through the ordering, provisioning and setup phases, the last thing he wanted was to experience it again in the high-growth startup context. “I believe it’s a focus drain” Quentin explains. Searching for a way to avoid the issue, he found out about Heroku. “It’s honestly magic! When I want to add a server, I just push a cursor and get 10x more power, it’s unbelievable.” And Quentin goes on “My role is not to make any point manually installing servers on my own, but to make sure my guys are spending time on the right issues for the product and the company.”
The overall course of tech resources optimisation
|Completely externalise tech knowledge by buying software licences.||Drive your company developments using free knowledge bases.||Focus developments on your core business & outsource everything else.|
|Software licences||Open source||SaaS products|
Quentin de Chivré specifies that this philosophy followed him throughout the stages his product and startup went through. “Once funds have been raised, you’re still in a scarce resources situation, you’re still trying to prove you can create value with limited resources, and so you’re still focusing your energy on the very thing that adds value to your product,” Quentin points out.
3) Favor working the way your team does best
Quentin has a propensity for finding hidden costs. In addition to resorting to SaaS tools to avoid the hidden costs of human resources, he chose to handle the migration from Titanium to native development for Shopmium’s mobile apps in a very specific way.
“Frustration was building up, so it was time to move on to native development. We could have paid an agency to deal with the project for 6 months. But choosing an agency means losing knowledge about your product, which usually later translates in maintainability and evolution difficulties. You don’t want your product to be petrified in time. Costs may be more controlled, but agility is lost. Or we could have dealt with the 6 months project internally, but we did not have the knowledge for it,” Quentin says.
“The team and I knew how to deal with little iterative projects. Others might know how to deal with huge projects and possibly respect deadlines. But we did not. So I was not going to send my team in it, we were going to do it as we know best.”
Shopmium’s tech team thus started looking into Titanium insides and built a hybrid techno of a native app embedding the existing Titanium code, with scaffoldings joining migrated parts to the ones that were not yet migrated. The first release was about the subscription tunnel, then it was about a tab, and so on… They were able to release every month or so and did not face an enormous validation phase at the end of the project, when nobody ever remembers what they did 6 months ago. With their shorter sprints Shopmium’s team members remembered clearly what they had developed a short while ago, they could easily maintain and patch the live version.
“It first appears to be a more expensive solution, but we did not drag a failing project over long overdue deadlines with a demotivated team. We were working the way we do best, and it even allowed us to include some features evolutions in the mix.”
Put extra attention in maximising your output
1) Process with baby steps, what’s valuable is unpredictable
Building up a startup means testing a lot of things. “There’s a lot of things you try, knowing full well that you might have to trash it later on if users or the market do not pick it up” explains Quentin. “We tried Shopmium Mission for example, which was addressing the need of a new set of professional customers for in-store data. We tried, but it turned out to be complicated to operate and with little value for us, so we let it go.”
“Moving forward is done with a lot of fumbling around, it’s the very core of a startup. With every little wall you encounter, you understand what works and what doesn’t, and you end up building something that works.”
Quentin de Chivré believes Simoncelli once said something about startups being like fold blinded rats in a labyrinth, bumping into walls. “You go straight ahead and you bump into a wall. You turn right and you bump into another wall. Little by little, through bumping into walls, you find your way. You code, and you code, and your product develops in this way too.” Quentin clarifies that this is also the reason why they did not chose to proceed with a 6 months long project when migrating from Titanium to native code. “With a long term project, something would end being delivered after 6 months, whether it really works for your product and business or not.”
Which also means that Shopmium’s roadmap was voluntary hazy, and as Quentin puts it “it is still now, but it was especially so in the very beginning. You don’t want to spend time specifying each and every feature you’re going to build over one year. After only 3 months, once you’ve realised some features add value while other don’t, priorities will have changed. So working with a 3 months plan seems as far away in time as you can manage to not dig your grave with unrealistic product visions.” In the case of Shopmium, the tech team had a global vision and a course to follow, and with every small release they were learning what made sense. Their platform was zigzagging, but towards one direction.
2) Finish up your roadmap with business
It’s crucial to make sure you have a global direction for your product that gets activated by your company’s clients needs. “It’s not about having an archi. absolutist vision. My co-founders and I would agree on possible features for the upcoming year, and they would enter the commercial deck. Once this roadmap was globally defined, we told sales they could sell whatever feature they wished from it. And as sales were approaching closing deals with specific features included, we would develop them in priority.” Quarter after quarter, Shopmium’s tech team was thus developing features that were both part of their product vision and perceived as especially interesting by the market.
“With your roadmap, you have to strike a balance between an absolutist architectural vision and developing features that stick to sales and marketing needs. A product is only a good one if it is valuable to some clients somewhere.”
Working in this way allowed Shopmium to avoid spending time on developing features prior to really knowing if they had any actual appeal to anyone, thus potentially losing energy on lost causes. Of course it meant being extremely agile as once end users are getting interested, features need to be developed quickly and beautifully. Shopmium thus developed with coherence because of the initial impulse being driven by product vision, while being activated according to business needs and real-time client feedbacks.
Quentin goes on “Minding the business and making sure the product is a good fit for your company business is a necessity. And it might mean accumulating some technical debt. But in the end, your product fits market needs, it is sold and it scales. Then your can look into technical debt.”
More CTO stories to come. Get them straight to your inbox & sign up to the blog!
Love this? Share it!