Product mindset for Software Engineers
By: Dhruv Agarwal
Tags: Product Engineering, Product Thinking, Product Development, Software Development, Product Management

Product mindset for Software Engineers

Are you a software engineer who wishes to take product decisions but is unable to due to the way your team functions? If your mind is screaming YES, then this article might help you to have a better grip on the product mindset while being in the shoes of a software engineer. Dhruv Agarwal Follow Dec 19, 2020 · 4 min read

credits: hackernoon.com

Truly speaking, a great software engineer is the one who can utilise his/her skills to make a great product.

Software engineers are the frontline in any tech company and more so in a tech product company. However, you would find that most of the software engineers lack good product sense despite being great in their software knowledge.

The fundamental problem lies in how the work is assigned in most organisations. Software engineers are given tickets to work on. Typical examples are:

“Create an API to login with email”



“Create a cron to put credits in customer’s accounts”

The issue is that tickets only carry an instruction to “implement” something. The person making the implementation decision could be your manager, your product manager or someone senior in the team.

That’s exactly where the damage starts! You don’t know

Who is going to use the login API,

is going to use the login API, When those credits need to be put,

those credits need to be put, What will be the frequency,

will be the frequency, Why login with email and not Facebook,

login with email and not Facebook, Why are we putting credits?

What happens next? The feature goes live but fails at some areas and it comes back to you with more requirements and again you’re given some improvements and directions from either your manager or product manager.

Do you see the problem here? The problem is you lacked context.

Had there been context, you’d have taken the right calls as per the situation. With less context, you go with the constraints that you can think of and take the decisions accordingly for the interface, complexity, architecture.

There is no silver bullet for either of the interface, complexity, or architecture. It depends on the scale of the problem you’re solving, the user who is going to use the product and the frequency of the use.

Here is how you can change a ticket to gain more context — Make it a story.

credits: jotform.com

Story

A story has a character, his/her motivation and their success. Let’s understand this by using the earlier example of a ticket — “Create a cron to put credits in customer’s accounts”. Now let’s ask some questions to build the story.

Who is telling our system to add credits? — Someone from marketing/growth

is telling our system to add credits? — Someone from marketing/growth Why are they adding credits? — To nudge customers to buy your services at some discount

are they adding credits? — To nudge customers to buy your services at some discount When do they want to add? — They might add towards month end when users might get their salaries and are more likely to make a purchase

do they want to add? — They might add towards month end when users might get their salaries and are more likely to make a purchase How are they most comfortable adding it? — They use a CRM tool to send us a list of users with the respective credits to be added.

Now, if you try to write this story, you’ll get something like this

“As a marketing manager, I would like to nudge prospect customers to buy our services. One way I can do that is by adding credits in their account around the payday and nudge them to make a purchase. Users are more likely to purchase during that time. If we can automate this flow from the CRM to add credits to prospect customers, it will help us drive more revenue from the users.”

As you may notice, there are no technical instructions at all, but has complete context.

Being a software engineer, you are responsible for thinking the best technical solution for this problem. Now you can make the best interface for the right user, understand complexity better, make the right architectural calls. For eg- this feature is more likely to have load around the month end only and you need to quickly finish that load.

How are stories better than tickets?

Stories as compared to tickets not only give complete context but also give room for innovation and guarantee success, whereas tickets just guarantee execution. Stories let you take the decisions too rather than just limiting the thinking part to your manager or product manager.

You can also challenge the proposed way and propose simpler ways to achieve success within your product.

So remember - next time you receive a ticket, try to convert it into a story. A story will have a character, his/her motivation and success.

Hope you find this framework useful and step ahead in your product-tech journey!