3 Suggestions to Make the Product Process More Enjoyable
Working on a company’s core product can be really enjoyable. Those involved in the product process are given the chance to make decisions that affect our users and the company’s fortunes. But working on product can also be a real pain. Everyone has an opinion, and often there is no clear way to make decisions. All too commonly, the product process breaks down and, by default, the highest ranked / paid person makes the call. Clearly this isn’t great as they often lack the right context. Worse, it can be pretty demoralizing for everyone else involved to see that their input is effectively ignored.
At Codecademy, we’ve been looking for ways to improve our product process. In the past year, we’ve emphasized three elements which we think have had a really positive effect for our product decision-making: product principles, chain of decision-making and culture. None of these ideas are particularly novel, but I thought sharing how we make use of them at Codecademy might be helpful to other companies working through their product challenges.
Product Principles
First, we openly discuss and rank which arguments carry more weight than others. If everyone understands and buys into this argument hierarchy, this greatly speeds up the decision making process.
At the bottom of the hierarchy of arguments is individual opinion and anecdotal evidence. At the top — for most startups at least — is data from randomized control trials (A/B tests). This is the cleanest type of data: the gold standard. But there are times when A/B testing is not possible, or not the most appropriate way to move the product development process forward. A few months ago, we released an updated version of the product that combined both cards to give users learning context, and then took them to the code editor. The new product had functionality we wanted users to have which the old one didn’t provide. It didn’t make sense to A/B test the old against the new product because they did different things. And A/B testing couldn’t help us figure out how to build the new product.
This is where “product principles” come in. Product principles are core tenets that we believe are fundamentally true. At Codecademy, ‘product principles’ trump data from A/B tests. A key product principle we hold is that ‘learning by doing is better’. Even if A/B data said that watching videos was better than our existing product, we would not walk away from basing our product on learning by doing. Most of the team are here because of a belief in this principle, and it also happens to be our core differentiating factor. That said, if all our efforts to produce a product that satisfied that principle were not well received, we’d eventually have to look at whether we had the right product principle.
As we’ve evolved our product and learnt more from our users, we’ve been able to lay down a number of product principles. If ideas cannot satisfy those principles, they can be quickly tossed aside. In the absence of clean data, using the principles makes it easier to reject ideas without getting personal — I love your idea but unfortunately it doesn’t quite square with our product principles!
Chain of Decision-Making
At Codecademy, we’ve set up formal roles for the process of making each major decision, with clear rights and responsibilities attached to each role. We use a DRI structure. For each decision, we have a D (decision-maker), an R (recommender) and I’s (inputters).
The D has the most context for the problem to be solved and is the ultimate decider. They set the objectives, constraints and measures of success for the R. The R then takes the objectives, constraints and measures of success and does 90% of the work to make a recommendation about what the decision should be. The R decides which I’s to gather input from, and does a lot of the hard thinking. The role of the D is to hold the R accountable, to ask the hard questions and to guide the R. Ultimately, the D must make a decision based on the recommendation brought forward by the R. If the decision goes well, the R should be praised and recognized. If the decision does not go well, it is the D who is held responsible.
We have found this structure helpful in a number of ways. First, it encourages the R to take risks and be bold. Instead of worrying about having to protect themselves from blame, they are incentivized to be creative. Second, it makes it very clear who the D is and what they must do. Third, it helps decentralize a lot of decision-making. The DRI has meant that we have been better able to get the most appropriate person to make decisions, but within a clear structure that hopefully gives them the best shot at success. Before this DRI structure at Codecademy, we’d often wait for the founders to make the decisions. This did not scale and led to bottlenecks. Not so good! The founders used to be the D for all product decisions, but they are now often I’s, with the product owner becoming the D. Obviously there are regular product meetings where the founders’ input is sought, and it is rare that product decisions are made that would be directly contrary to what they think. But we think it’s a healthy situation where it’s possible for the product lead to make a decision that disagrees with the founders’ inclinations. This works because the relevant D reports directly to the founders so will be held accountable come performance review time.
Culture
The final element that holds everything together for us is having a strong culture. Even if you have really clear product principles and a well-functioning DRI structure for big decisions, none of this works if the people involved are jerks. If people are unwilling to put aside their ego because they really think their idea is better, product principles be damned, it is hard to have a functioning product process. Similarly, if the D or the R cannot take feedback from other stakeholders, product principles or DRI structures aren’t going to help. The founders lead by example here. Without their willingness to put their ego aside and trust others to make key decisions, none of this would work. At Codecademy, we do our best to screen for future team members who are coachable, and low-ego. As has been said by many others before, it really does all come down to culture.
Before I joined Codecademy three years ago, I didn’t know what product meant for online businesses. I thought products were like cars and t-shirts. Thankfully my kind colleagues have taught me about lots of online products! But improving a product and building new products is a bigger challenge. Trying to get the best out of all the different talents in the team requires a structure clear enough everyone knows how they can contribute, but loose enough that it can change quickly as the business’ needs change. We’ve found that making use of product principles, the DRI structure, and being clear about the cultural attributes we want in our team-mates, have all contributed to a much more effective (and enjoyable) product development process. We’re growing our product team and hope that these foundations will help us scale effectively.
