“Say NO” to paying users

UPDATE: I’ve moved over to a new blog, you can find me at https://bytesroute.com/

Building software products means constantly listening to your users and iterating on the product by taking that user feedback, analyzing it and deciding which improvements will help your users the most. Obviously
those will be the features that will help your product grow too.

Saying NO

The hardest part in this process is to decide what NOT to work on. It’s tempting, sometime even addicting and sometime simply easier to do what the user thinks it needs. Experienced engineers know when to say no, when to say yes and when to take a step back, take a look at the bigger picture their trying to solve and decide what is the best solution.

The Pareto principle applies to building software products as well, so make sure you do your best work on solving those 20% of the problems and you’ll get that 80% of return on investment.

If you had a feature delayed for 2 years, or more, because other more important improvements were required chances are that this feature is NOT that important for most users after all and you should not waste precious time to work on it now.

Instead of simply picking the next issue from Jira, take a few moments to analyse the big picture of your product and try to pick that improvement that can have the biggest impact for your users. If you don’t know which one to
choose, than you should ask for advice from the team (colleagues, product manager, marketing, support …).

Team members working on those improvements that only seem important, just to feel busy, are not simply wasting their time and the resources of their team, they are slowly but surely paving the way for the product’s death.

Keeping yourself busy is not why your team trusted you to join them, they trusted you’re smart enough to know when to ask for help, courageous enough to admit you don’t know everything, to be honest with yourself when you feel that something is not right and give your best try to make it better.

That is all that you have to do, to give your best, day in and day out. Careful here, this does not mean working 24h a day, 7 days a week. It simply means giving your full attention and energy while analyzing the user problem and potential solutions.

When every member of the team will give his best chances are 99% the product will be a success, users will be happy with their investment (even if you don’t build all they asked for), they’ll recommend your work to others and every team member will be rewarded.

Hope @Jack won’t mind me borrowing his words, they’re pure inspiration:

Limit the number of details and execute each detail perfectly.

P.S. I’m just starting on this personal blog, follow me if you want to hear more of my thoughts and also let me know yours…