On Choosing What To Do Next

Image credits: Alejandro Polanco

So, you are a technical leader and you and your team is building a product. There are a lot of moving parts: the requirements that constantly fail to be static and well defined, the company’s infrastructure is moving forward somewhat, the codebase you are working on.

How to keep the development efficient and not stall while some decisions were not made just yet? How to tackle changing environment? What to do next on the project?

I use a simple heuristics that I found very useful for that.

The Heuristic

Image credit: Natalio

Imagine your product should be released just now.

Will that happen? No? Why exactly? What is blocking it?

Be very specific about the reasons and put it into one of the two buckets: technical reasons and product reasons.

I use terminology a bit loosely. The product reasons are the features that should exist in the product.

If all the reasons why your product won’t be released today are solely in the product category (like, it can be deployed today, it is tested, but one of the critical features is missing), then you have nothing else to do than start working on this missing feature.

Usually though, that’s not the case. There are plenty of technical obstacles to be solved or avoided before the product can be released.

I suggest to focus on the technical issues as soon as possible.

**Why focusing on technical issues first?**Business is not static. While you are building the product, requirements and priorities might shift a couple of times. You, as technical expert, need to keep product in a releasable state all the time, with any set of features.

**The Technical reasons**Some types of technical reasons to think about:

1. Deployment. Do you already have all the servers up and running? Is there a build/deploy script? Are all the store accounts set up? Are signing keys or SSL certificates already in place?
2. Analytics & Monitoring. Is a crash reporter integrated in your app? Do you monitor all the parameters than you need to monitor?
3. Security. Was your app security-reviewed in any way? Do you use a strong encryption? Is your auth/auth safe enough for the wild west of the Internet?
4. Was the product thoroughly tested? Are the existing features good enough to be released in public? Are all the assets correct?
5. L10N & I18N. Is the product localized? Are the translations ready and checked?
6. Legal issues. Is the EULA ready? Is the Privacy Policy up-to-date? Did you mention all the libraries you use? Are all the 3rd party libraries have right licences?

Some of these technical reasons might sound pretty non-technical. But technical decisions aren’t only related with the code written, they are much more than that.

Not all the reasons might be easily go into one category, or another.

Sometimes, you might get blocked by some agreement or just email chain or something else. Don’t just wait for it, remember the concurrent programming model and switch yourself to the next reason unsolved.

This simple heuristics helped me a lot with building my projects, and I hope it will help you to build yours as efficient as possible.