We are a product team.
By Jeff Bordogna
Here at Relay Foods, we don’t have a Technology department, we have a Product team. The reason for the distinction can be seen in our team’s vision:
We want to be the team that connects people with food through technology. This means helping customers find the right food for them, whatever/whenever is most convenient. It means making it simple for people to find, prepare, and enjoy healthy meals. It means connecting people with their food producers, as well as their tastemakers (friends, bloggers, celebrity chefs, whatever.) It means using technology as a force for good in the world.
The key phrases are “connects people with food through technology” and “using technology as a force for good”. While the technology bit is interesting to us (and we certainly spend a lot of time thinking about it), it pales in comparison to the time, energy, and passion that we pour into the end products that get built with that technology, and even more so the people touched by those products.
It’s not at all the case that being on a “technology team” is a bad thing; we frequently refer to ourselves as “technologists”. It’s just that in our case, interesting things have happened as a result of building a team around the “Why” (the product) vs. the “How” (the technology):
- We don’t (yet) have a dedicated project manager on our team — each of us is actively involved in leading and/or participating in the projects we ultimately build tech for.
- There is no lengthy requirements process — again, because the people developing the technology are intimately involved in business decisions, there is no need for a lengthy “technical contract”.
- We’ve adopted a Design Thinking strategy in order to creatively but efficiently tackle complex problems. This methodology has since been adopted in other areas of the company.
- The hundreds of micro-decisions made every day (in fixing bugs, choosing copy, etc.) that affect customers don’t require approval because the team has the clarity and context to make the calls.
- Roles are loose, and the culture of learning is important, because each of us is looking for ways to adapt / fill in gaps in order to make the end products better.
- We use a set of agile concepts because they form a natural path towards quickly reacting to customer needs, not because they’re part of some “decided upon” management methodology.
If this sounds too good to be true, it’s because it is! Building software, especially software that truly solves people’s problems, is really, really hard, and we’d be lying if we said that our approach hasn’t seen a number of obstacles or that it’s any sort of “finished” state.
But, despite the many obstacles, we really think our “product first” approach has enabled us to not only be more empathetic to our customers’ needs, but also much more efficient in addressing them. Our tiny team of 6 has built, currently maintains, and continues to innovate on a set of products that combines e-commerce, inventory/fulfillment, and delivery/logistics — and I couldn’t be prouder of them.
We’re looking forward to sharing more about our vision, processes, and yes, technologies, not because we think we have it figured out, but because we’re hopeful there are some tidbits worth learning from that can be helpful to the broader technology/startup community that we learn so much from everyday.
To that end, stay tuned for an upcoming post by Chip Lay, who’ll be discussing our recent “landing page refresh” project, whose goal is to help customers more immediately understand the value of Relay upon arriving to our site.
PS — Sound like something you’d be interested in being a part of? If so, drop us a line.