I see many PMs itching to create a product, be it for their internal customers or the external customers. So many PMs are trying to build ERP solutions, payment gateways, survey tools. I find this urge to create mostly in those who got into PM from dev roles, so that itch to write code and delve into testing a new tool is understandable. What about the PMs from a non technical role? How do they create a Product or what is their approach to create a new product?
It’s human nature to focus on the solution than the problem because we assume we know what our customer needs. We been program to think solution first before understanding the problem which is the number one mistake I see PM or Product Teams make. Take time to really understand the problem/opportunity and your customer before determining a solution. Majority of the time, the solution you come up with isn’t the one customer wants or it was only good idea in your head then reality.
"Many PMs itching to creating a product”, a bitter fact, and hence, majority of PMs and Product Team focuses on building solution no one wants because they believe they know what the customer wants without interacting with them. In addition, it’s human nature we are wired to be solution first then problem therefore, we go and work with UX and Dev with our ideas without ever testing our assumptions. I don’t doubt with 15 years of experiences you may know what your customer needs are but majority of the time, most PMs or Product Teams don’t and will build solutions no one wants.
I disagree entirely because of scalability. you going to go out and interview millions of customers? No, you’re going to talk to a few hundred at best and make decisions off of that feedback. Also, if you build well enough for thousands, its likely you will accommodate millions. I don’t have all the answers, and I can be wrong. But I will say I can easily detect if something is shit before it sees the light of day.
Rigorous problem definition backed by data. I have no clue what millions of people across 14 different markets want. Interviewing hundreds of people would be a waste of time because unless you were able to ensure the survey were statistically significant who can say if they are even representative of the population. But you can locate oddities in data and work backwards to logically identify the precise problem that is driving a well quantified portion of the data oddity.
One should always consider whether to build, buy, or partner… all three are valid at various times. Being able to understand when each is valid and how to execute on each approach will get you far.
Adding to this, while building a product might get approvals, the future improvements for internal tools are always bleak because of various constraints. So, you will be stuck in a weird place for migration of data to a suitable tool. It’s easier to use tools that have built in that space if you can afford to. Unless you want to market the product externally, the improvements are always going to be slim.