The purpose of this document is to define a change in the culture and operating processes of our software development program within Levels. This primarily applies to everyone working in Product, Design, as well as both Growth Engineering and Product Engineering, but it also impacts several other company functions.
For all practical purposes, @Sam Corcos is going to be directly running the software development program at Levels at least through the end of the year.
Some of this change is born out of necessity given that have a much smaller Product and Design team than we did previously, so we need to rely on our Engineering team to deliver against a more diverse set of responsibilities.
The biggest element of this cultural change is that we’re going to trust our engineers to take more ownership in the software development process, and engineers will be responsible for selecting, scoping, implementing, measuring, analyzing, and reporting the results of their projects (more on this below).
Everyone in Engineering is expected to play a role in the product development process. Product determines the “what” and the “why”. What metrics do we need to move? What should we deliver to move those metrics? What user need are we solving?
We’re reducing our dedicated Product resources to just 1 person: @Cosima. And her primary focus will be to talk to our customers, learn what their needs are, and propose what we should build to deliver against those needs.
Emphasizing the note above, everyone at the company has a role to play in Product, and it’s the role of the Product org to think through and prioritize what we spend our time building. Product makes the call on product values we prioritize and build for.
Going forward, Product is not going to be responsible for the day-to-day blocking and tackling of ticket and project management. We’re going to have to rely on our engineers to project manage and communicate effectively. Engineering DRI will define project timelines, deliverables, and scope when a project goes into Ready for Development stage, with input from Product.
Design determines the “how” we solve a user need identified by Product. Some of the concepts that Design will work on are brand new explorations of concepts, and some of what Design works on will be polishing or updating existing features.
As of May 27, 2023, our Design org is just one person: @Viktor Engborg. This means that we’re going to have to rely on Engineering to use their discretion on design considerations much more often than we have in the past. This will increase our velocity, but it will also put pressure on Design.
We need to be mindful of the Design resources we have available, and it’s important for @Viktor Engborg and @Sam Corcos to stay in tight sync to make sure we put our limited design resources towards our highest priority projects.
The most likely outcome of this process is that Design will typically start by delivering lower-fidelity concepts and wireframes to Engineering — and there will often be occasions where the engineers themselves take a first pass at the designs — and we’re going to rely on Engineering to understand the intent and flesh things out themselves. At some point, Design will take another pass to increase the quality of the feature if the feature proves to be a success.
To analogize this change, we’re shifting to a process that’s more like image interlacing (image on the bottom left), where we start with a low-fidelity version that we ship with the help of Engineering that resembles the final version, rather than starting with a high-fidelity but incomplete version that starts with Design (image on the bottom right).
While Product determines the “what” we build at a high level to move our company metrics, Engineering also has a voice in that conversation, and they are responsible for coordinating with Product and Design to ensure that we’re building features that deliver the value that we intend to deliver.
<aside> ⭐ Going forward, we’re going to trust our engineers to take more ownership in the software development process, and engineers will be responsible for selecting, scoping, implementing measuring, analyzing, and reporting the results of their projects.
</aside>
This means Engineers will be involved in and take over ownership of the feature development process earlier-on. This also means Engineering will need to spend more time in understanding customer experience, to be able to contribute to the early conversations of feature development process, and form opinion on what user impact a feature is going to have. There are multiple ways to get to understand customer experience, including but not limited to: using our own app and dogfooding new features, staying close loop with Support team, joining Community calls, sending and synthesizing user surveys, building and monitoring app engagement dashboards, etc.