Product development at SamKnows

SamKnows started as a small, highly-skilled team where everyone knew what was going on. Communication was easy, and we scaled fast. But to ensure our rate of change was sustainable, we decided to adapt our internal workflows. Particularly since we're still scaling! Here's what we've learned so far.

Like most companies, SamKnows started in a single room where everyone sat at the same table. Knowledge sharing was easy and communication effortless. Everyone knew everything! We worked hard and we scaled fast. Our small development team churned out new internet performance metrics, test agents, and analysis. We accelerated from measuring internet performance of thousands of homes, to many, many millions. 

The Router SDK allows the full SamKnows measurement functionality to be embedded inside a broadband router.

To keep pace, we created a brand new cloud-based analytics system called SamKnows One, to which we’re constantly adding new features. It can also crunch vast amounts of data - but that's another story

We hired extremely talented people and continued to set our sights on the future. But all this focus on external change meant that we spent less time adapting our internal processes, and this became a problem - especially since we’re still scaling fast. 

Identifying problems and inefficiencies

We realised we had issues with our process of working so we decided to change. But first, we needed to identify exactly what those issues were.

1. Prioritisation
Slack had become our way of prioritising builds, to the point that whoever pinged the most ensured “their” feature was given priority. This frustrated everyone, apart from Saja who thought it was just great, (she gets stuff done!).

2. Validation 
Tasks were moving straight to build without assessing whether the feature was going to add value to our customers. We spent a lot of time working on wonderful ideas that were never used.  

3. Build
As disciplines grew, they became more siloed. Before we knew it, we were working as separate groups. This is no bad thing if all teams are communicating with each other and it’s clear what needs to be done. However, a project would start with a “kick off” meeting, involving lots of different teams, only to progress into a development process where people would work on tasks in isolation. Each discipline had separate Jira boards and stand-up. As soon as a team completed a task, they would pass it over to the next in what felt like playing Chinese whispers and hot potato at the same time!

Important information fell through the cracks and this meant that development was task-focused, with the overall purpose lost. People didn’t understand what they were building or why, nor how it would affect the end user, or even where their work fitted with the company’s vision. Time for change!  

Implementing our new development process

So, six months ago, we embraced experimentation. There have been lots of articles written about how tech companies should build their products - but we took different parts of these methodologies to create a process that is right for us.

It sounds obvious but one of the largest changes we made was to move to a shared backlog on Jira. This has given us visibility over our entire roadmap and allowed us to implement a new prioritisation process… (not Slack!). The next step was to establish cross-discipline teams to work on the shared backlog, called feature teams. 

Feature teams are made up of front-end developers, back-end developers, and designers who sit together and work on the same things at the same time. UX and Design also play a big part in the process so that everyone shares the same vision for the product, and are accountable for the outcome. Our company culture is all about collaboration, where every person’s opinion counts. This is similar to the very successful Spotify Squads model

The importance of discovery

Perhaps the most important phase that we have added is the Discovery phase, which involves the entire feature team and the product owner. 

The purpose of the Discovery phase is to achieve alignment, validation, and reduce risk. During this phase, we figure out three key things:

  • Who is the feature for? 
  • Why are we making it? 
  • What is it? 

We first agree on a problem statement, goals, and base our approach on the research that we conduct (i.e. survey evidence, data, risks, user testing, and user stories). We then sketch our solution outline and agree on the next steps. If we find that we need to tweak the initial plan for the final outcome to be successful, then we do. However, everyone has a chance to contribute their thoughts and is informed throughout. We like to be flexible, so long as everyone knows what we’re doing. 

Sometimes, following the Discovery phase, we veto the proposed feature, saving us money, valuable time, and protecting our developers. We then quickly move on to the next thing.

Developing at speed

Initially, our main focus was to empower our collaborative working style, which is a big part of our company ethos. Dividing into smaller, cross-functional feature teams where each team manages its own workload and builds in an agile, iterative way, has already improved feature ownership, prioritisation, and quality. Most of all, our new processes mean we can continue to scale at a rapid rate.

Matt, our Lead Back-end engineer says, “The planning process allows us to dive far deeper into each problem and explore potential solutions. The Discovery phase provides us with more frequent business and customer feedback which means we can prevent wasted effort and improve the quality of our product delivery. When we trial, we reflect back on how we can improve our processes - we’re always working to enhance our new workflow and take everyone’s opinions into account. By the time you read this we will have changed something, but we’re certainly heading in the right direction.” 

Your expertise is valued here, as is your wellbeing and career. By addressing the bumps in the road, we were able to change things quickly and work towards a more beneficial work style for everyone. Our new workflow means that we are better equipped to adapt to sudden change, sustain our company growth, and succeed. Product development is now significantly faster and of a higher quality than before, and with a shorter time-to-market for all products and features. 

If you like the sound of our new way of working, and want to build innovative products that contribute towards a better Future internet, join us! We're hiring.