A Startup Centric Mindset
The motivation for this post: throughout my experience working with many startups, I have rarely seen developers who think holistically about the problems they are supposed to solve. The dilemma we face here is that we sometimes work on products that we are not the immediate users of, so we start making assumptions that may or may not be valid. And sometimes, our users develop habits to work around issues that exist in the product or need entirely new features that are not present in the product in the way we originally intended.
This post will discuss my approach to understanding the customers' needs and feel their pain, and I will give examples from my current work at Zid. Keep in mind that this is my approach, and it may not be as effective for everyone. Also, this is a mindset, not a recipe, meaning it takes time to get it to be part of your intuition, but having the ideas laid out would help you actively think in the following sense.
Note that some of these ideas may sound contradictory, which they are to some extent. You will have to make tradeoffs as needed in your situation.
Be In The Customer's Shoes But Keep The Analytical Hat
As developers, we like to think of things as procedures or a series of logical steps. This mindset is what allows us to write programs out of problem statements. However, your customers are not developers, and they may not know the right questions to ask or how to find the root cause of the pain.
When talking to the customers, you need to forget all your preconceived notions about how the customers use the products or, at the very least, validate them. In other words, do not assume that the user uses the product as you designed it. They might have created new use cases or altered old ones in ways you never thought of.
When you get a feature request, your first intuition should be to ask your customers why they want this feature, and what problem does it solve. Something to keep in mind here is that you should be careful of rephrasing the feature statement instead of discussing the pain. You need to focus on the whys, not the hows, to get a deeper understanding of the issue, instead of suggestions for solutions; failing in that could lead to solving an entirely different problem.
For example, merchants at Zid asked for bulk price updates for their products. After further discussion with the merchants, it turned out that the goal is to make store-wide sales – they wanted to edit the prices beforehand. Here, we asked: what happens when the sale ends? Is it possible to revert the changes? What happens to the product variants? How practical is this suggested approach in achieving the goal?
You Know How To Automate, But The Customer Knows The Business
Now that you understand the problem they are facing. You can start sketching different workflows as your solution candidates. Here, you should be thinking more about which parts of their current process are causing the most headache, how you can eliminate them, what are your current parameters, and what steps are redundant.
One way to tackle these questions is to treat your process as a pipeline of inputs and outputs, where each pipe is a step. You then start removing pipes to see how that affects your flow and the needed inputs to the next step. More often than not, you find that you could either combine steps or remove them altogether because the system already has all needed inputs to execute a particular task – meaning human intervention is redundant in the first place.
Building on our previous sales example, we came up with auto-applied coupons given that we understood the intent behind this feature request. They are coupons that are automatically applied to the cart based on specific rules (e.g., total, shipping address, particular products, etc.). This approach allowed for many more features to be built on top of it, and the requested feature is just one application of this more flexible solution (discount on any cart during the sale).
Do Not Write All The Code At Once, No Matter How Detailed And Thorough The Requirements Were Given – They Will Change
Part of finding the best approach to automating a task is testing it with real customers. Implementing the whole thing all at once and releasing it is the total opposite. Especially if this is a reasonably new business, you will be making a lot of assumptions with very little usage data to back them. I call this premature automation (automation of not well-understood operational procedure). Premature automation could force you to adjust what you already implemented in ways you did not intend, leading to unnecessary refactoring. Keep in mind that you don’t need to refactor the code you didn’t write.
In other words, you should write the minimal amount of code solving the most basic case of the task, then test it with a real user. Once you made sure that your have a sound and solid foundation, you can build the next layer on top of it, and so on.
Give The Knobs To The Business Team
This point may be more specific to internal automation. You want to keep yourself out of the daily operations. Changing a service's price or name should not be only possible by the developer (either through the DB or hardcoded in the codebase). Try to make your parameters easily adjustable by your operations team.
For example, at ZidShip, our team can use our backoffice to alter integrated couriers, from updating pricing models to changing messages to manipulating routing rules for each courier without going through a developer.
However, this may not always be feasible. In some cases, adding these toggles may not be worth the effort put towards it – that is, if changes are infrequent and trivial. But again, do not underestimate the impact of having such options available.
Closing thoughts
This mindset is meant to complement the product manager's role rather than to replace it. A developer's thoughtful input into the product development cycle can significantly enhance the end user's experience. The product manager's role is to be in the company's front line when talking to the customers and getting their feedback, but the developer should still be as keen to learn about the customers. Moreover, the product manager should be mindful of trying to get the full picture to the developer.
Again, do not expect to master this overnight. It will take some time and effort in actively thinking of the right questions to ask to design such well-thought solutions.