Product development: Less is more, and 'no' is the new ‘yes’

When we develop products, the ability to say ‘no’ to certain things plays a huge role. Why? Because there are always lots of ideas for new features, lots of directions we can take, and lots of strategies we could implement. It can be quite hard to say no, especially when there’re so many possible ideas and directions to take. 

As developers, designers, and product managers, remember that the ability to say no can come in very handy, especially when someone suggests introducing a new policy or process in response to a problem. 

We often rush to create new policies in response to problems, immediately, seeing these as salvation. We do this because it protects us from future mistakes. It makes us feel safer if we think "policy X ensures that problem Y won't happen again". 

But I’m convinced that 90% of the time it’s much better to have an honest discussion about the problem, suggest possible solutions, and trust your team to implement these solutions

Here are a couple of examples that help explain the above.

Let's say a bug got into your product. The team noticed it and fixed it, but not without complaints from customers. Then, after the fact, the issue becomes a hot topic, and someone suggests: "This should have been caught at the code-review stage. Why didn't anyone notice this bug? Now Jeff (some smarmy developer/designer) has to approve all code reviews. And let's make a rule on GitHub that there must be two approvals before code is merged.”

The problem is serious: a bug appeared and affected customers. But the solution seems like overkill. Sure, code reviews are important, but suddenly Jeff is a gatekeeper. Merge requests are likely to start piling up because Jeff, who has limited time, has to review each one. 

We also shift the responsibility for contributing code from the person who knows the details of the functionality best to someone with less knowledge (in this case, Jeff).

How to avoid gatekeepers

I'm not saying that code review by multiple people is bad, especially if a talented developer is involved. It's great practice. But there is another option: trust that you can talk to the team about the problem and that they can deal with it responsibly.

Back to our example. Try saying, "Guys, let's get more active in code review. Don't merge your merge requests until you get good reviews and feedback. If there are no reviews, don't hesitate to ask for them.”

This holds developers and designers accountable for what they contribute to the code and does so by trusting them. Also, as experts in the field, they're contributing to, they may know which of their peers is the best reviewer of their work, and can ask them for a review. Trust that you have responsible adults on your team who can behave in a professional manner.

Our backend developer Dmitrii Kozlov gives some tips on how to avoid mistakes in your code review process and make it more valuable in this article.

At MadAppGang, we have two principles in our code review guidelines that express this trust and responsibility:

1. Remember that your job (as a reviewer) is to provide feedback, not to stand guard.
2. The merge request author makes the final decision on changes.

Let's say that in the last iteration, several tasks were poorly specified. This required a lot of discussion between the developer and the product manager to find out exactly what needed to be done. 

During the retrospective, the developer raises the issue and the team decides to have a general meeting every Monday to discuss each task before the next iteration.

Again, the problem is very real. Poorly executed and described tasks require a lot of extra work before implementation. It can cause serious delays in the release of new features. But now we move from one problem to another: creating a weekly meeting that takes an hour from 8 people. That's 8 working hours — a whole day!

What to do with these "elusive" tasks?

As in the previous case, the alternative is communication and trust. Let the product manager know that the tasks were poorly described. Ask if there were any difficulties in compiling them. 

In this case, perhaps the product manager can communicate more with developers and designers before starting. But instead of setting up a weekly meeting, try to trust the product manager to be more proactive in getting feedback when needed. 

If the problem occurs again, discuss it at the next retrospective. Maybe the cause will be different next time.

It's easy to make rules. It's hard to get rid of them

Making new rules is usually the easiest. But getting rid of outdated rules can be the hardest. And the more rules there are, the more rigid the process becomes. Rigidity slows down the speed at which your team iterates. 

So while introducing a new policy may seem like a small step, it can end up being a big cost in the long run.

A quote from Rework in the chapter "Don't scar the first cut" describes this problem as well as I can:

“Policies are organizational scar tissue. They are codified overreactions to situations that are unlikely to happen again”.

The alternative is communication and trust. It allows the team to remain flexible and adapt quickly. It also empowers people to take ownership and does not require rigid instructions from the top. New policies should only be introduced into the process when really necessary. Don't leave immediate scars.

How much process is ideal?

Of course, the optimal amount of process will vary from company to company, and the process should adapt as the team grows and changes. At MadAppGang, we've had great results with a flexible process and two key principles that encourage open communication and trust: daily synchronisations and weekly retrospectives. And more often than not, that's often enough.