How we built Campaign Wizard using Feature Teams

With the launch of Campaign Wizard, we experimented with a new approach to product creation. Known as ‘Feature Groups’, Adjust created a task force of individuals from around the company to help guide the product from initial brief to launch. To find out how they work, and what this meant for the development of Campaign Wizard, we spoke to Hector Satre, our VP of Product, to find out more about the feature, and the team who helped shape it.

Adjust is a tech-founded company. When I joined there were about 20 to 30 of us, and we all wanted to learn as much as we could.

Everyone was technically and generally well aware of what we were up to as a company. Not only was Slack very active, but we were here till very late, solving problems, and gaining more understanding of what each person was doing and how that changed the product we were all invested in.

It helped that we started small. We had a backend team which was, when I started, one person. In the dashboard team there were three. For our SDK, one person. Admin, also one. This meant that the communication was straightforward. We did not onboard at the same time but we all worked at the same speed, and the product was small enough that each person knew every corner of it, and if not, we were all in one room to talk about it.

As the company grew, we brought in more specialists to handle particular functions. While these people were very good at what they were brought in to do, we found there was a trade-off in the knowledge that they had of our tech. The product grew in complexity too, meaning it took more time to learn. It became harder to keep up with the first wave of Adjusters, and the specialists were keen to focus on bringing their expertise to the company to provide value in their own way.

We developed from a company where everyone could understand the full program and communicate really quickly between each other to larger teams, longer lines of communication, and a lesser understanding of the whole.

What is Campaign Wizard? What’s different in this next release?

In its first form, Tracker Wizard was a giant leap for attribution technology, simplifying the entire process of creating tracker links. Trackers themselves are a fundamental part of attribution - without them, you couldn’t track.

In the past, the creation of trackers used to be manually intensive and required both app publishers and networks to handle various parts of the process. With Campaign Wizard, all that was needed was a single link in order to create a tracker. Overnight, many of our clients fell in love with the feature.

However, one shortcoming of the feature was that attribution settings were only able to be set at the app level. This means the attribution settings are the same for all app marketing campaigns. So, app publishers couldn’t run different types of retargeting and user acquisition campaign for the same app at the same time or A/B test different settings.

For example, attribution windows couldn’t be altered per campaign on a single app. So, say you have an app and you’d like to run two campaigns with different networks, and with different goals: one is to target users who haven’t been on your app in 90 days, another for users who’ve lapsed use in the past day. Before, you could only run one instance. With the update, you can now run both campaigns at the same time. This is because you can adjust the user inactivity window for retargeting right down to the adgroup level. This works on any campaign.

With the new release, Campaign Wizard gives marketers complete control over their campaign logic, and furthers their ability to work on different campaigns in clever new ways.

When developing a feature, in the past each team was independent. Each would have standups and normal agile processes, but they were all isolated from each other. For some time this wasn’t an issue as communication was smooth. Slowly, with growth, we saw communication become less efficient. The misunderstandings grew, and synchronizing was not as easy as it had been in the past.

We had to actively communicate with people within the company to let them know of what was to come, whether it was a new product or a slight alteration. Also, there were more people involved, from start to finish, or from the initial brief to the promotion of a finalized product. If someone wasn’t involved who had crucial knowledge or involvement, their voices wouldn’t be heard, which led to problems.

And I was in the middle! All the information needed to go through me, to the point where people weren’t communicating with each other without my oversight. This was pretty difficult to manage - not only to gather information but to communicate it to everyone else. This could not possibly scale.

So we came up with this idea of what we call ‘Feature Groups’. A feature group is a multifunctional team that’s created for each new feature release, with a mix of both broad knowledge and specialization to create balance. This means that we can have representation from each team in the production and launch of a new feature.

These people could be from tech teams; backend, frontend, database, but also marketing, education, support and so on.

The way we structure this is to get these people briefed on the first day with a breakfast together. During the meal we have a series of questions prepared, and the group discusses the feature, the goals we’re trying to reach, the problems we have and what the landscape looks like.

After this, every day we have a standup meeting where everyone talks about what they’re doing, their completed tasks, difficulties they’re facing, and changes to the project and the direction.

How are Feature Groups structured?

Initial briefing breakfast

To begin, the group would come together to discuss the brief and the eventual goals of the project.

Stand-up

Every day the group would ‘stand’ together to talk about the developments of the past day, and the intended tasks to complete that day. This allows each member to keep aware of each other’s work, and provide feedback from their own view on what each other are doing, and how expertise can feed into each role.

Trello

We use Trello to organize everyone's individual progress from each team for each feature, tracking progress, making suggestions on different parts of the workflow, and changing as new ideas come in.

Friday debrief

On the final day of the week, the group reviews the previous week to see what’s been changed, and how the product has developed from all perspectives in that time.

Launch

On the final meeting, the group has dinner together, where they go over the processes, looking at how the project developed and identifying improvements to be made for both the product and for the group.

We try not to focus on personal stakes - as in, going too deep into technical or marketing jargon which could lose the interest of the room. This is because it could be too far from someone's understanding, and we wouldn't want to lose individual interest when everyone should be able to contribute to the conversation.

The real goal is to keep the points brought up in the meeting simple, so when a member of the group shares their experience everyone can get what they’re talking about, and contribute to the discussion. If there’s more input needed, then we can apply deeper knowledge to the problem.

Every Friday we have a weekly debrief, and at the launch we have a group dinner, going over the past process, what changed, and what we can improve for the next feature. We also look at the brief and compare it with the final spec to see how it changed and evolved over time.

How did the initial brief change over the process?

The brief the team started with was broad. The longer they looked at it, the more it became apparent that there were some crucial things missing.

So, the process changed - a column in our Campaign Wizard Trello board appeared, “improvements”, where any time a team member saw a possibility for something to improve, or for a gap to be filled, they would create a new card.

One suggested improvement was to address the attribution settings. These settings were broken up by click-based, view-through and reattribution. Inside the first a user would find device ID and fingerprint. It’s the aim of the team to change this to split click based into its subcategories, creating four views: device ID, fingerprint, view-through and reattribution, which is a relatively large structural alteration.

So far we’ve seen improvement in direct communication - people are no longer relying on the project manager (or me(!)) to make decisions they now can own themselves. That, and they’re talking to each other without going through us. It’s brought a good level of personal empowerment and autonomy, which helps bring back the agility we used to have.

The feature group has also shown us that everyone can bring their own ideas, and their own ways of improving the feature to the table. For example, documentation and training were previously coming into view late in the process, and in a rush to write the materials needed to educate. This meant that they didn’t feel involved, which affected their work too. Now they’re there from the beginning, bringing ideas on how to create great features for our clients.

The difficulties of building a new product will always be grounded in technical problems. With feature groups, the possibility to get these out into the open, and mix them in with different perspectives means we can reduce errors, and produce better results.