What’s it like to build software for a start-up that’s helping other start-ups build their own software? Recently, I sat down with Florian Motlik, the Chief Technology Officer and co-founder of Codeship, to find out. Codeship was founded about three years ago with the idea of making software testing, development, and deployment as simple as possible. As CTO, Flo has been responsible for making sure Codeship’s technology works, though he says that when you co-found a company, you “start off really technical and then get less and less technical as time goes on.” Flo decided to build Codeship with his two co-founders because he worked on software in different contexts and found deploying new code to be a massive time sink for the companies for which he worked.
This suggests a key tenet of Flo’s philosophy both for Codeship and for Codeship’s customers: “speed wins the market.” If you’re running a start-up with five competitors each trying to win market share, you’d better be fastest, he says. Codeship helps other companies do just that: beat their competitors by being faster than they are. Software development is an inherently iterative process, according to Flo. You must constantly test and refine your code or you’ll fall behind. Many companies self-host their own testing platform, but Flo argues that this diverts their development teams from solving the problems on which they should be focusing. What’s more, it slows down the entire organization because of the time required to push out new code. The wasted time degrades the company’s ability to compete in the long-term because, remember, speed wins the market.
It’s a bit like hiring an accountant to file your company’s taxes. You could forego the cost of the accountant to your company and dig into the Internal Revenue Code yourself, but you would likely waste lots of time that could’ve been better spent improving your product. The same applies to Codeship, but even moreso: Codeship can help you improve your development process so that every time you need to push out an update or a new feature, you can do so faster. Frugality is necessary for any start-up, Flo says, but there is a risk that you will be too frugal and end up losing the market to a more nimble rival who was willing to spend a little more up front to build a better development process. Even if your software is better than your rivals’ today, Flo says, it will be worse tomorrow and still worse the next day if your competitor has a better process than you do because of how fast the software industry moves.
Of course, the speed with which a company moves to market must be counterbalanced against the time necessary to build more features. This tradeoff of speed versus features is among the most difficult things that any start-up must weigh, but in the software industry where speed counts for so much, it is especially difficult. Flo counsels that development can be cyclical. First, you spend time building or improving the core of your product. Then you push out that core and transition into building new features. Once you have developed those features and pushed them out, you can start to refine them to make your product better suit your customers’ needs. One quarter, your company might learn about what improvements are necessary to make the product better and the next quarter, it might act on that knowledge.
This is where the iterative nature of software development comes into play. To refine, a company must always be testing. It also points to another key point in Flo’s philosophy: a company must be in constant conversation with its customers about what they want and what their “pain points” are in using the product. However, it isn’t sufficient for a company just to be talking to customers. It must be talking to the right customers and asking the right questions. Sometimes, of course, customers won’t necessarily know what they want. As Henry Ford said, “If I’d asked people what they wanted, they would have said faster horses.” (We have no evidence that Ford ever said those words, according to Patrick Vlaskovits of the Harvard Business Review, but it makes for a pithy soundbite.) While there’s some truth to the logic of the Ford quote, customers are an invaluable resource for a company seeking to improve.
Flo argues that the key to learning from customers is segmenting customers and finding the correct ones with whom to connect for feedback. There is a danger, in Flo’s experience, of reaching out to too many people and spending time generating information that is not useful. Metrics become crucial at this stage to identify who is the correct type of customer with whom to connect. As an example, Flo said that recently Codeship had rolled out a new feature that helped different teams work together across bigger companies. Many of Codeships clients are small companies who have less of a need for this product than its larger customers. It would have been a waste of time (and speed wins… I think you get the idea) to reach out to the smaller clients to get feedback about a tool for which they would have no need. The key is investing time upfront to think about precisely at whom a new tool or feature is targeted before spending the time to gather information.
Flo also suggests that if customers want a new feature, you will often want to have a longer discussion about precisely why they want that particular feature. After digging deeper, you might find that there is a better way to solve the customer’s problem than to do what they suggested. In order to foster this sort of dialogue with customers, Flo says that your Support and Development teams must work together closely. This can be difficult because both teams have so much to do, but Flo argues it is essential. Indeed, Flo says that you should have a more expansive role for your Support team, which must do more than support other functions of the business. That’s why Codeship changed the name of its “Support” team to “Customer Happiness.”
One simple way to see which parts of your product might need refining is to use your own product yourself. Codeship deploys and tests its code using its own software, and Flo stressed the importance of using your own product so that your team will understand the user experience. If you are using your own product every day, Flo said, you might notice subtle things that would improve the product but fall down the priority list if you weren’t using your own software. Because you’re using the software every day, however, your team will be motivated to make the changes that will improve the product in the long-run. You also build a visceral attachment to your product that is essential for any start-up. A start-up will take over your life, so you’ll need to love your product like it’s your baby if you’re going to stay motivated! That attachment doesn’t take place if you aren’t using your own product and “feeling the pain,” in Flo’s words.
In the end, Flo suggests, Codeship is selling a process through which you can enhance productivity and win the market. Ultimately, Flo says that Codeship wants to be the one tool for your entire development process and “control your entire workflow” because, as a company, the co-founders of Codeship understand how important speed is to building a successful software business. When developing software, it can be the difference between success and failure.