Introduction

"It doesn't make sense to hire smart people and then tell them what to to. We hire smart people so they can tell us what to do. " - Steve Jobs

Time to start working, and if you're like me, your main responsibility might be writing scalable code along with a good suit of unit tests. If you're lucky, you may even ship something to production without bugs. Life isn't so bad, right?

What if I told you it could be better? As a software engineer, we can contribute much more to the solution we are developing to achieve a product that has a real impact. That makes our job more challenging but also more engaging and satisfactory.

With luck, your company and your team have good sense and provide you the autonomy to act with this kind of ownership, so this article may help you to be a better professional by showing how you can positively influence your product at 3 steps of the product development lifecycle.

Product discovery

"It doesn’t matter how good your engineering team is if they are not given something worthwhile to build." - Marty Cagan

This is the stage before you actually grab that task from the backlog and start coding. For each task that hasn't been started, your mission will be to answer only two questions:

What is this task impact?

I'm not saying people randomly choose features to be delivered (sometimes they do), but the goal of them has to be clear. Is it raise the conversion of a signup form? What is the current conversion and what number are we aiming for? How many users will be impacted positively by this feature?

How can you possibly know about these things? Isn't your job just hard enough? Well, yes it's hard, but study a little about your company business and your users won't kill you. Better than ship something to production that no one will care about.

Is this task worth the effort?

When you select a task you're always deselecting another one, so you have to consider this tradeoff in a technical way. And there's no one better than you to make this decision because you're the software engineer and maybe the person that will develop the selected task.

Usually, you should prioritize tasks that have low effort and high value, because you can deliver value earlier to your users and you have less risk to ship a bug or regret an architectural decision.

Development

"At least 2/3 of our ideas are never going to work. The other 1/3 will take 3-4 iterations to get right" - Marty Cagan

Finally, the best part of our job, right? Just put your headphones and code in the zone. And we're even get paid for this.

Sorry for maybe screwing up your dream, but sometimes we, and I'm including myself, become immersed in our art and forget that our job is still to deliver value to our users and our company. You can still work on your craftmanship, just don't forget about this:

Don't fall in love with your feature

The goal here is to avoid the Big Design Up Front (BDUF) because you don't know what you're developing will work. That's why you should try to deploy it the earlier as possible, without over-engineering but don't compromise (too much) the quality of your software.

The deploy step should allow you to collect feedback from your users, and if they don't like it, don't feel ashamed to drop your feature and delete all your code. That was another product experiment after all.

Make it measurable

How do you measure your success? I prefer the simplest solution for this, which is using an analytics tool, like Google Analytics. Just point-and-click and within seconds anyone can have their answers, no need to know SQL or programming.

So every code you ship now should also be packed with its respective tracking or something else you could rely on. Sometimes I even use the application log.

Deploy

If coding was good when you were just a programmer, now that you have a product mindset, the deployment should be the happiest moment of your life.

Time to track

Observe if people are using your new feature and if that improved your product somehow. Hopefully, you and your team have done a good product discovery, and now your users are happier. You can even use the analytics data to catch some strange behaviors (like bugs).

Next steps

Based on your previous observation, you now know if your experiment was successful. If not, that also counts as learning, because that new piece of information can be used to pivot your product.

if that latest feature was a success, you should decide to continue improving this solution or start exploring another one. By improvement, I also include a technical debt you've decided to delay or a performance issue to scale this recent feature to 10x more users. And thanks to your effort in instrumentation during the development step, these decisions are easier to make since you have all the analytics data.

Conclusion

Just repeating what an intelligent person said: our job isn't to deliver code, it's to deliver value, and code it's just a mean to achieve this.

Thank you for reading, hope you've enjoyed it!