Tech companies often kid themselves they have cross-functional teams. But if you have, say, a mobile app team that has a product owner, iOS plus Android developers, and a mobile UI specialist… where’s the cross-funcionality, exactly? At Estimote we preach that context is king and teams with a delusion of cross-functionality can never really understand user’s context. And then the product suffers.
Earlier this year we decided to put our money where our mouth is. We embarked on an experiment to restructure the whole company around the context of our customers and their journey with Estimote products. Here’s the first part of what we learned.
Estimote team at work
What happened?
We used to have typical product teams. We had teams responsible for Estimote Cloud, the SDK, hardware, our mobile apps, and Estimote Indoor Location. We were following the common knowledge that it lets companies move quickly and affords them flexibility. It’s often not the case.
To give you an example: we have thousands of people using Estimote Cloud. Some of them have just three beacons and they use the cloud to generate and store their app projects. Others have deployed hundreds of beacons and Estimote Cloud’s web dashboard is where they manage them. Some resell beacons as part of their own products and mostly use the dashboard to reassign beacon ownership to their clients. It all falls under the umbrella of Estimote Cloud but it’s one hell of an umbrella. How is one product team supposed to manage all these scenarios?
We wanted more context in our product development. So we asked the whole team - what’s the best way to work? How do we want to structure? For two days, Estimote was divided into groups of five or six people, each with the same task of figuring out how we should structure the company to reflect the customer’s context.
The discussions were framed in terms of our vision - building an OS for the physical world. But the how was defined by each and every one of us. We had top-down vision and bottom-up here’s how we should do this”. We wanted different perspectives to cross-pollinate, so the groups consisted of people who didn’t work directly with each other on a daily basis.
After two full days of heated discussions, every group submitted their ideas. The management then took a couple of days to review them and shape the final structure. What emerged was a company built around the customer’s journey, with each team responsible for developing and maintaining products that serve our customers on one stage of this journey.
What has changed?
We’ve settled on the following teams that represent subsequent steps of the journey:
Awareness Awareness team’s goal is to make sure developers around the world know and love Estimote. This means inspiring and educating people about beacons, contextual computing, and microlocation via this very blog, social media, and our YouTube channel.
E-Commerce The EComm team takes over when someone shows purchase intent. From SEO, to the website, to the purchase flow and shipping, they make sure everything goes smooth and visitors convert into customers. And if you ever needed to change the address of your order, they’re the folks you talked with.
Developer Experience The moment a customer receives their devkit from Estimote, they’re in the hands of the DevEx team. User onboarding, demo apps, tutorials, basically anything that helps developers get up and running with our stack. They recently brought you the updated Proximity Beacons with NFC support.
Integration The next stage is moving from prototyping to figuring out how to integrate Estimote Beacons into your app. Integration team takes care of the SDKs and documentation to enable you to do just that. Oh, and by the way, they just released a huge update to Estimote Stickers.
Deployment That’s our in-house group of mad scientists that know everything there is to know about deploying and maintaining the physical infrastructure of beacons. Optimizing beacon placement for best possible signal coverage, Indoor Location SDK, walking customers through the nitty-gritty of rolling out hundreds of beacons: that’s their daily bread. The Deployment app that lets you upgrade your whole beacon network in no time is their handiwork.
SaaS You have your app polished and published, the beacons are placed, all is going well. Now what? Now you want to be sure that managing your fleet of beacons is painless. That’s where the SaaS team comes in. Their latest update was Estimote Here & Now messaging technology.
We’re still doing a lot of work that doesn’t belong to a single part of the customer journey. The Operations team handles administrative tasks that let the Estimote ship sail smoothly. RF Reliability is, paraphrasing Matt Damon, sciencing the sh*t out of Bluetooth so other teams build on their work. Customer Success is here to make sure that Estimote users can scale up their projects and transition between consecutive stages of the journey. They, along with a couple of others, all exist as standalone teams, which does not mean they’re not a part of the core structure. You can think about them as the foundations and the scaffolding of Estimote. Without them we couldn’t build anything else.
Yeah, but does it work?
We have redefined what a product means to us. We now treat each step in the customer’s journey as a product. For example, Developer Experience’s product is not a single element of our stack but rather a complete set of experiences a new customer has with beacons or stickers in their first few days of prototyping. That means taking ownership of all the interactions between a developer and Estimote tools, be it changing beacon settings with the Estimote app, downloading an App Template from Estimote Cloud, or submitting a support ticket because their first project doesn’t compile. We kept intact the agile mix of daily standups, two-week sprints, and scrumboards but it’s lighter than a vanilla scrum. Each team has some autonomy to tweak the process to their needs. If Awareness organizes a hackathon and Deployment develops a new algorithm for Indoor Location, it’s only natural they’ll do it differently.
For this to work, product managers need more diverse competences on their teams than in a standard structure. Previously, our team responsible for Estimote apps consisted of mobile developers and UI designers. That’s an illusion of cross-functionality, exactly the problem mentioned in the beginning. For comparison, aforementioned Developer Experience also needs a hardware engineer, a community manager, and a technical writer. SDK team used to be mobile and backend developers but Integration also requires embedded developers to work on beacon firmware.
This caused some chaos with new teams assessing their needs and competences but now we start to appreciate the agility it affords. Dependencies used to slow down development previously, because if you’re trying to move fast, you always end up with more work than people. Giving teams ownership of everything in their step of the customer journey means more independence. And independence is a good rule of thumb for assessing your team’s cross-functionality. More independence means shipping more often. If dependencies slow you down, maybe you’re not that cross-functional?
And what about consistency? On this end, we’re not straying far from a more typical structure. We borrowed an idea from Spotify’s engineering culture. People who share a skill set meet regularly to compare best practices and stay on the same page with brand guidelines. We call them Guilds (we’re not using the word in the same way as Spotify). The incredible thing about Guilds is that they’re a bottom-up initiative. No one told Estimote developers to meet weekly to watch and discuss talks about programming. No one asked product owners to sit down together regularly to chat about different aspects of shipping. It’s a byproduct of people taking ownership.
Estimote team, still at work
Estimote journey
Building product teams around the customer journey is an experiment. And one that makes sense specifically at Estimote due to the nature of our product.
With a typical SaaS product, the funnel is straightforward. You get people to see your website, then some of them convert to a free trial, and then some of these convert to paying customers. In our case, it’s more complex. We convert some visitors into customers and they buy a devkit. Some of them start prototyping. Some of those prototypes are turned into apps. Some of the apps move to a pilot stage. Some pilots become large scale deployments. The cycle can take months and consists of enough stages for our approach to make sense.
Still, the transition hasn’t been exactly smooth and it took us a couple of weeks to adjust. But since then, it’s been going along quite well. We ship faster. We talk to customers more. The feedback loop between Estimote and our users is much shorter. Only in the past few weeks we launched our latest and greatest video beacon, Mirror, presented Estimote Monitoring to deliver better microlocation interactions, started shipping the next generation of Proximity Beacons with NFC,and updated Location Beacons with 200m range. Not bad, huh?
Of course there’s still a TON of work to be done and improvements to be made. And we’re constantly looking for new people to join the mission of creating an OS for the physical world, so if you feel like that’s a place where you belong, don’t hesitate to get in touch!
Wojtek Borowicz, Community Evangelist at Estimote