I once worked with two developers who had the ability to completely lose contact with reality: they worked for several days sleeping just a couple of hours per night. They advocated this method, saying that deep concentration was the only way to tackle complex problems. They were brilliant engineers, but sleep deprivation has a very destructive impact on behaviour and inhibits the ability to work together with other people. The collaboration did not last for the long-term.
Having worked with many a workaholic (and admittedly having been one of them myself), I tend to be diffident when I’m working with someone who tends to isolate themselves and spend too many hours in front of a computer: everyone needs to have a minimum viable social life and interests in things unrelated to work. If you’re too individualistic, too monothematic and like to work alone, it’s less likely you’ll be a good team member.
The cast of Silicon Valley
As I wrote in my previous post, keeping the who team on the same page is the first thing you must to do to maintain team discipline and increase productivity. Communication between the members is crucial. At Stamplay we use whiteboards to plan activities and have a quick overview of what’s going on. Recently, we created a Slack channel that we use to do a daily check-in: we have adopted this method because the team is divided between Rome and San Francisco and we only have a very short window of time to talk and discuss.
Maintaining an effective level of communication, even in a small group, is not so obvious: several times I’ve seen poorly managed workgroups where people didn’t know what the colleague sitting beside them was working on. It’s a dangerous situation that can create a lot of frustration. When a team member is not integrated with the rest of the group and doesn’t feel at ease, they become less productive; they lose motivation and move their attention to things that have nothing to do with the result to be achieved.
More important than team communication is communicating with your customers; it’s hard to be productive when a developer starts a project without having a clear understanding of the problem that they’re solving and the needs of those who use the product.
Developing a digital consumer product is difficult – more difficult than creating software for a customer as a consultant. When someone commissions a project, they tell you what they want to get (more or less, but that’s another story…). Obviously, it’s helpful to understand why the client is asking for a specific feature, but the consultant it is not necessarily responsible for whether the market analysis is correct and whether it makes sense to build the project in the first place.
When you run a startup and create a new product, things change: product management and software development stages are almost contextual. You make hypotheses to be tested in the field, then you organize tests and you learn from user feedback. And so it goes while you build up knowledge. Each step requires the development of new pieces of software, and sometimes it turns out that your assumptions were wrong and you have to throw it all away.
When you read books like The Lean Startup, it seems so easy: the reality is that organizing a useful test, collecting feedback properly and pulling the right conclusions is incredibly difficult. The most common mistake is that you tend to organize the build-measure-learn cycle in such a way that it produces reassuring results. This will keep you in your comfort zone and is the best way to fail.
At Stamplay we made a lot of errors, especially at the beginning: we thought that our idea of using an IFTTT approach to allow the development of web apps was so brilliant that anyone would have shouted “Eureka!” So we went directly to design and implementation of a system that went far beyond what we could have done with our resources. We worked isolated from the world and ignored any criticisms. That was exactly the opposite of what we should have done, considering that we had studied the lean startup methodology, customer development, the blue ocean strategy, and many other books.
For some strange reason, we “self-validated” the assumptions and remained in our comfort zone. For a great part of 2014 we just listened to those who told us that we had a very interesting approach and that our platform had a lot of potential. This was certainly true, but it said very little about how to effectively design the product, what the key features were, or what should have been the customer acquisition strategy.
Late last year we knew we had to make a decisive change by focusing on doing just one thing. We decided to drop part of the product – effectively wasting thousands of hours of software development – and we redesigned the user experience with the goal of making it more friendly for professional developers. At the same time, we raised a Seed round to realize our new vision.
Putting a sharper focus on our target market allowed us to reorganize the way we connected with our users. Today, the dialogue takes place in many different ways:
- Intercom is definitely one of the best CRM and marketing automation systems on the market today. It’s the tool we use to activate and support our users.
- Slack has become a communication standard for many teams. That’s why we decided to create a community channel for all our users.
- In the first eight months of 2015, we participated in or supported several events for programmers and hackers in Europe, including the API Days in Berlin and JsDay in Verona. We also partnered with various Startup Weekends and hackathons worldwide.
- We connected with bootcamps to dialogue with instructors and have students adopt our technology as part of their curriculum.
- We set up a complete tracking system for our digital properties using Segment to track anything from a first visit on a blog post to the first app created. This is helping us to understand how developers get to know and choose us.
My co-founder Giuliano illustrates Stamplay platform during an hackathon in Berlin
Marketing to software developers is very difficult. They’re among the most demanding customers around and they are very choosy when it comes to investing their time to test a new technology. Obviously I understand it: the web is full of frameworks and solutions that promise to optimize the work of software developers, and the time available to discover and test these new tools is always too little.
It’s no surprise that most of the companies in our space adopt a bottom-up approach, creating a community around their technology, being incredibly supportive and publicly releasing some of their intellectual property as open source products.
This the second post in a series of thoughts about software development and productivity. I’m not a programmer, but I’ve worked with programmers for the last 20 years in a variety of roles. View the first post here.
This post was originally published on Stamplay Blog.