Hi Ai! Thank you so much for the kind words. We’re so happy to have you as a People-First Jobs company.
Team structure has been fluid over the years. I’ll start with what we’ve been doing recently, and share a bit about where we want to go.
For a long time, we’ve had teams dedicated to working on specific products. Our biggest product, Postmark, has the largest team. We have a product manager, Rian van der Merwe, who works with folks in design, engineering, and QA that only work on Postmark. Our CS team, led by Dana Chaby, is also dedicated to a single product. And there have been marketing folks dedicated just to Postmark.
The Postmark team has a very structured planning and execution process. Because it’s the largest team, it has the most communication overhead. And because it has so many customers, we treat it differently than a brand new product.
The smaller products have much smaller teams, maybe 2-5 people. They keep their process extremely lightweight by doing their own support, product management, and customer development. We allow those teams to stay scrappy because there is less risk and less overhead.
Then we have some teams who support all the products, like finance, infrastructure, and marketing. Those teams either act as advisors to the smaller teams, or take on clearly defined projects that we map out during quarterly planning.
In the entire history of Wildbit, we’ve encouraged folks to move around the company and work on other products. That’s core to what makes us special. But we try to make those changes no more than once a year, so you can really dive deep into the problems we’re solving.
Starting next year we’d like to be less siloed. We don’t want to have Postmark developers, but instead Wildbit developers. We want a Wildbit customer team, not Postmark customer team. In the immediate term not much will change, but over time we want to be able to leverage the expertise of these folks across all products, and to allow our team to keep moving around inside of Wildbit. This will also help us use our economies of scale to start more projects and not get bogged down. If our engineering team is cohesive, we can reuse principles, move faster, and have consistent processes.
Re: how we decide what to work on. Since we are a smaller team that doesn’t work on 10+ features at a time, our process is fairly straightforward. We follow a quarterly planning cycle, and we rarely plan product roadmap that extends beyond that horizon. So we start with defining our Vision & Focus for a quarter at a company level, and then our teams work together to figure out the best product bets we can place to help accomplish those goals.
We take user needs (through constant ongoing research and collaboration with the customer success team), business goals, and technical needs into consideration to decide on the prioritized themes for a quarter.
Importantly, we don’t plan it all out upfront and make commitments we can’t keep. We start with a project plan that frames the problem we want to solve, and that plan evolves as we progress through the quarter — as we learn more from our customers & competitor research, and as we dig into solutions and discover the best path forward.
At the end of a project or feature we make sure we gather feedback from customers, and make time for our teams to adjust and improve as we learn more from them. And then, in most cases, we start the next quarter fresh. Sometimes that results in a continuation of a particular feature, sometimes it’s something new based on a change in Vision & Focus, but we always go back to those principles, and work in collaboration with the team on how to make the product better. To put it another way, we aim for our team (and their extensive knowledge of customers) to be the product visionaries in the company.