A mini-rant I went on this evening prompted Jason Edelman (@jedelman) to suggest I write a blog on the topic. My rant was in regards to job rotation. Specifically in the IT vendor world rotating from the field (sales-engineering, professional services, technical support) to the business units building the products, and vice versa. This is all about perspective.
In the past I’ve written about pre-sales engineering:
The Art of Pre-Sales: http://www.definethecloud.net/the-art-of-pre-sales/
The Art of Pre-Sales Part II – Showing Value: http://www.definethecloud.net/the-art-of-pre-sales-part-ii-showing-value/
Pre-sales engineering (at Value Added Resellers) has been my background for quite a while. About a year and a half ago I moved over to the vendor side, and specifically a business unit brining brand new products to market. This has been an eye opening experience to say the least.
What I’ve Learned:
- Building a product, and bringing it to market is completely different from using it to architect solutions and selling it.
- This one almost goes without saying. When your selling a product/architecting solutions you are focused on using a solution to solve a problem. Both of these should be known’s.
- If you’re a good architect/engineer you’re using the two ears and one mouth your given in proportion to identify the problem. Then you select the best fit solution for that problem from your bag of tricks.
- When you’re building a product you’re trying to identify a broad problem, market shift, or industry gap and create a solution for that. The technology is only one small piece of this. The other focuses include:
- The Total Addressable Market (TAM)
- Business impact/disruption to current products
- Sales ramp
- Ever sat back and asked yourself ‘What were they thinking?’ 9 times out of 10, they were.
- 9 out of 10 of those times they were thinking TAM.
- We tend to work in specific verticals (as customers or vendors): health care, government, service-provider, etc. What seems like a big requirement in our view, may not be significant in the big picture being addressed.
- Shifting markets and therefore shifting TAM. Where you may be selling a lot of feature x today, that may be a shrinking market/requirement in the big picture.
- Complexity/down the road costs. In many cases implementing feature x while complicate feature A, B, C, and D. It may complicate Q&A processes, slow feature adoption, add cost, etc.
- Nothing is free, engineering resources are limited, time is limited, budget is limited. This means that tough decisions have to be made. Tough decisions are made in every roadmap meeting and most of those end with features on the chopping block, or pushed out.
- Anything added typically means something removed or delayed. In cases where it doesn’t, it probably means a date will slip.
The Flip Side:
This is not a one way street. The flip side is true as well. My lifetime of experience on the other side gives me a far different perspective than many of my colleagues. Some of my colleagues have always lived in the ‘ivory tower’ I now live with them in. Without having experience in the field it’s hard to empathize with specific requests, needs, complaints or concerns. It’s hard to really be in touch with the day to day requirements and problems. Having the other perspective is beneficial all around.
- If you’re an IT vendor find ways to open up job rotation practices. 3-6 month rotations every 2-3 years would be ideal, but anything is a start. Advertise the options, encourage managers to support it, promote it.
- If you’re an individual, suggest the program. Beyond suggesting the program search out opportunities. It’s always beneficial to have a broader understanding of the company you work for, trying different roles will help with this.
- Even if neither of these things can happen, find ways to engage often with your counterparts on the other side of the fence and listen. The more you understand their point of view the easier it will be to find win/win solutions.