Experimentation has become a key part of every startup’s toolkit. Experimentation is required to figure out what your customers really want. You come up with a hypothesis, build something, show people, listen to what they say, learn and try again; in short: build, measure and learn. But what is easy to forget is that you need a culture to drive this process that comes from within. To build a great product, you need to be prepared to experiment with your people and process too. Otherwise, you’ll just be talking about a pithy startup mantra that you haven’t fully embraced.
Experimenting with People
Now, when I say “experimenting with people” I don’t mean give half of your team some performance-enhancing nootropics and the other half a sugar pill. The culture of work is changing (if you don’t believe me, check out this infographic we made). At HubbleHQ we’ve had to adapt in order to keep good people and to make sure our team is happy, motivated, and productive.
A few years ago, one of our first product engineers told me he was moving to France and wanted to work part-time. This was no reflection on HubbleHQ, just that he was interested in experimenting with some of his own entrepreneurial ideas and had to move for personal reasons. Immediately, I was worried about the impact of this. Running around my head were thoughts like: “How is this going to affect team productivity? What if I say yes and then everyone wants to do this? Can we handle someone remotely?” However, I couldn’t shake the feeling that for a culture that promotes experimentation and flexibility, that this would be our first real challenge and that if we wanted to keep good people, then we’d have to adapt.
Tushar and I both agreed that this would be an experiment. Neither of us knew whether it would work but were willing to give it a try. We were open and honest with each other about the timeframe and said that we’d monitor the progress together. If it didn’t work, we’d both be happy we gave it a go. In the end, this has happened with a few people at HubbleHQ for various different reasons. We have one team member spending one week in Sweden and one week in the office and another who is now fully remote from Asia. By focusing on value and output and having an experimentation-based mindset, we were able to keep good people and keep them happy.
Interested in being experimented on? And experimenting with us, of course. Join our team!
Experimenting with Process
To give you an example, over the years we’ve moved from Trello to Jira, then back to Trello and back to Jira again. I don’t think this is because we’re indecisive. Or maybe we are….no I don’t think we are. As a company grows, it has different needs and different needs require different processes. That isn’t a big revelation, I know. The important part of experimenting with the process is that nothing is set in stone; just because a decision is made today doesn’t mean that it’ll be lasting and we can’t go back or change it later on.
Some of the experiments we have done at HubbleHQ:
- Jira vs. Trello
- Kanban vs. Scrum
- No-estimates vs. T-Shirt Sizes vs. Story Points
- Git flow vs. GitHub flow
- One big team vs. two smaller product teams
- and many, many more.
What is important is for the mindset to be embodied by the team. The team should feel no blame in making process or tech changes that they believe will have a positive influence. By having an experimentation mindset, you reduce the risk involved in suggesting and implementing process changes, much like when you ship new features.
Sound like the kind of team you’d like to be a part of? Join us here.
Experimenting with Product
Ultimately, all of the above drives product experimentation. By having the right process, the right people, and the right mindset, you can create an atmosphere that is reflected in the product you build. In general, I’m a big believer in Conway’s Law that “organisations which design systems … are constrained to produce designs which are copies of the communication structures of these organisations.” I can’t help but see how this mental model can be applied to other areas and that the values of your company will be reflected in what and way you build the product.
We’ve run many experiments over the years at HubbleHQ and, as you can expect, some have worked and some haven’t. Sometimes I think it can be depressing to be involved in product development. One can’t help but spot the flaws in their own product and are forced to embrace failure. On the bright side, when you do get it right, it is uplifting and a driving force to want more.
Frankly, we haven’t always done product experimentation well. I think everyone has experienced difficulty in applying the theory to practice; sometimes you try something but it doesn’t quite hit and you’ve already moved on and forget to come back and iterate; sometimes scope increases and you lose track of what you’re testing; sometimes you don’t have enough data to know whether it has worked or not, and sometimes you forgot to implement the metrics in the first place! You’ll rarely get something right first time round. You can just try to get it more right each time.
Learning from your failures is important and we mostly do this through retrospectives and weekly product catch-ups. Of course, learning before you fail is also great! More recently we have instigated a tech book club, regular lunch and learns, and the occasional away day (where we did a value stream mapping exercise that I highly recommend).
Our process, people and product are things we are always tweaking. This is so important because as a startup there is constant pressure to move faster – and as you grow that actually gets harder. So ask yourself, what can we test that could make our customers or our team happier, more productive or generate better results? This is something we constantly think about at HubbleHQ, and the only way to answer this question is to experiment.
