Experimenting with People, Process, and Product

By Tom Watson, Co-Founder & CTO , Hubble

Tom Watson, Co-Founder & CTO , Hubble

Experimentation has become central to every startup’s toolkit. It is required to figure out what customers really want. You come up with a hypothesis, build something, show it to people, listen to what they say, learn, and try again; in short: build, measure, and learn—the lean startup philosophy. 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 processes too.

Experimenting with People

The culture of work is changing. At Hubble, we have had to adapt in order to keep good people and 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 Hubble, just that he was interested in experimenting with some of his own entrepreneurial ideas and had to move for personal reasons. I was immediately 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 which promotes experimentation and flexibility, this would be our first real challenge and if we wanted to keep good people, we would have to adapt.

My co-founder and I both agreed that this would be an experiment. If it did not work, we would both be happy that we tried it out. In the end, this has happened with a few people at Hubble for various different reasons. We had 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, output, and having an experimentation-based mindset, we were able to retain good employees and keep them happy.

Learning from your failures is important and we mostly do this through retrospectives and weekly product catch-ups

Experimenting with Processes

To give you an example, over the years we have moved from Trello to Jira, then back to Trello and back to Jira again. I do not think this is because we are indecisive. As a company grows, it has different needs and different needs require different processes and tools. The important part of experimenting with processes is that nothing is set in stone; just because a decision is made today does not mean that it will be lasting and we cannot change later. What is important is for the mindset to be fully taken on by the team. The team should feel they are involved in making process or tech changes, which 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.

Experimenting with Products

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. I believe Conway’s Law holds true that “organizations, which design systems, are constrained to produce designs that are copies of the communication structures of these enterprises.” I can’t help but see how this mental model can be applied to other areas, and the values of your company will be reflected in product you build.

We have run several experiments over the years at Hubble and some have worked and some have not. Sometimes, I think it can be depressing to be involved in product development. One cannot help but spot the flaws in their own products and are forced to embrace failure. On the bright side, when you do get it right, it is uplifting.

I think everyone has experienced difficulty in applying theory to practice; sometimes you try something but it doesn’t quite work, 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 other times you forgot to implement the metrics in the first place. You will rarely get something right the first time around. 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. Our processes, people, and products are things we are always tweaking. This is so important because as a startup, there is constant pressure to move faster. As you grow, that actually gets harder. This is something we constantly think about at Hubble, and the only way to answer this question is to experiment.