When I was working as an engineer, I did what I was told to build. Specs were handed to me by my engineering manager spelling out exactly what he needed and how it should behave. When I had a question on expected behavior I could always ask someone else. More often than not I got answers to my questions.
Life was simple. As I gained more confidence with art of coding, I started to form my opinions about how to write faster and more efficient implementation. No matter how complex the problem was, I knew that I could apply Keep-It-Simple-Stupid principle and will come out on the other end with the least amount of code.
Then I moved on to become an engineering manager. Now I had to work closer with product managers. When a question arose, I had to collaborate with PMs to find answers. And to my amazement lot of times there were no cut and dry answer to many questions brought on by engineers. It could be done one way or another with questionable difference in final product marketability. More often than not, PMs seemed to make the answers up as they moved on without a good reason.
I challenged PMs many times when I suspected no good reason, and I found that it was very unsatisfying to hear a litany of justification from PMs' defending their own answers. It seemed backwards to come up with an answer and trying to think of a reason why it may have been a good answer to the question.
After a few years of spending time as engineering manager, I jumped on the chance to become a PM. I wanted to see the process of figuring out whether there is a market, reading market trend, and deciding what to build something that can sell.
After two years of PM experience under my belt, I can tell you one thing. PM does not know either.
PM does not know whether decision A versus B will make the product more marketable. Chances are that the decision won't affect the product success, if any. Maybe it will make it easier to use at best, and make it easier to demo and deploy.
I will tell you a more unsettling fact about being a PM. PM does not know if the product that everyone is building will sell. PM thinks there is a good chance, and knows there are other products similar that customers are using. But PM has no idea whether the product that everyone has been working extra weekends to release in time will actually be used by enough customers to make it all worthwhile. PM thinks it will. But there is no guarantee.
This is an extremely unsettling fact. One would think that when PM builds a product, PM would know exactly who will buy the product, how much customers are willing to pay, and how fast the product will be picked up by customers. But none of that is known. PM puts together the best guesses by looking at market research and competitors, yet it's bunch of educated guesses nonetheless.
There lies the problem with building a perfect product. There can be no perfect product. Every product is created with approximation made by PMs. Someone has better luck guessing what customer wants with fewer iterations, while others need more iterations to get it close to what customer wants enough to buy.
The key here is iteration. The best way to launch a successful product is to launch a whole bunch of not-so-successful products to learn from the mistakes. Well, almost. If there is a successful competitor, you can model your solution after the leader. That's the cheapest and surest way to introduce a product.
If I look back, now I understand why I never got sure answers from PMs.
Life was simple. As I gained more confidence with art of coding, I started to form my opinions about how to write faster and more efficient implementation. No matter how complex the problem was, I knew that I could apply Keep-It-Simple-Stupid principle and will come out on the other end with the least amount of code.
 |
| If you find yourself having this conversation, you need to adopt Lean Startup. Pick up Eric Ries' The Lean Startup. Short answer is release now! |
Then I moved on to become an engineering manager. Now I had to work closer with product managers. When a question arose, I had to collaborate with PMs to find answers. And to my amazement lot of times there were no cut and dry answer to many questions brought on by engineers. It could be done one way or another with questionable difference in final product marketability. More often than not, PMs seemed to make the answers up as they moved on without a good reason.
I challenged PMs many times when I suspected no good reason, and I found that it was very unsatisfying to hear a litany of justification from PMs' defending their own answers. It seemed backwards to come up with an answer and trying to think of a reason why it may have been a good answer to the question.
After a few years of spending time as engineering manager, I jumped on the chance to become a PM. I wanted to see the process of figuring out whether there is a market, reading market trend, and deciding what to build something that can sell.
After two years of PM experience under my belt, I can tell you one thing. PM does not know either.
PM does not know whether decision A versus B will make the product more marketable. Chances are that the decision won't affect the product success, if any. Maybe it will make it easier to use at best, and make it easier to demo and deploy.
I will tell you a more unsettling fact about being a PM. PM does not know if the product that everyone is building will sell. PM thinks there is a good chance, and knows there are other products similar that customers are using. But PM has no idea whether the product that everyone has been working extra weekends to release in time will actually be used by enough customers to make it all worthwhile. PM thinks it will. But there is no guarantee.
This is an extremely unsettling fact. One would think that when PM builds a product, PM would know exactly who will buy the product, how much customers are willing to pay, and how fast the product will be picked up by customers. But none of that is known. PM puts together the best guesses by looking at market research and competitors, yet it's bunch of educated guesses nonetheless.
There lies the problem with building a perfect product. There can be no perfect product. Every product is created with approximation made by PMs. Someone has better luck guessing what customer wants with fewer iterations, while others need more iterations to get it close to what customer wants enough to buy.
The key here is iteration. The best way to launch a successful product is to launch a whole bunch of not-so-successful products to learn from the mistakes. Well, almost. If there is a successful competitor, you can model your solution after the leader. That's the cheapest and surest way to introduce a product.
If I look back, now I understand why I never got sure answers from PMs.
Credit card provide you improve corrections could possibly be mainly high-priced, despite the fact that while understanding that, anyone check-up responsibilities linked with low-cost responsibilities mutually together with amazing household household personal loan price ranges, it could actually virtually absolutely absolutely expressed with inexpensive regarding the provide you improve corrections improve. You'll want to virtually absolutely ought to attain comprehensive to help spend $793 in mere aspect mutually together with responsibilities which includes a household home loan with standard loan company.payday loans direct lender corona
ReplyDelete