There is a huge assortment books on the market about marketing and sales. So much so that the category needed to be divided into two. While closely related there are harsh differences. When I initially joined IBM, it was known for its service orientation and its marketing organization. In hindsight, it was really its sales force mislabeled as marketing. IBM had lots of feet on the ground back then. There were marketing reps., account executives, and systems engineers that really had the role of sales engineer as well as a host of other titled roles for pre-sales. Sales and marketing was something everyone in the corporation did. Though not as directly as Marketing Representatives who were responsible for the actual sale and order taking. As a technical resource in the field I had two main responsibilities; 1) assist the marketing representative in finding and landing sales opportunities 2) assist the customer in solving technical problems. Most of the first was assumed would occur from activities supporting the second.
During my days as a systems engineer/industry specialist/programmer/consultant/architect etc. my domain of focus was industrial sector. This included engineering, manufacturing, architecture, construction, process industries, etc. The application of computer technologies to engineering and manufacturing was crossing the chasm to become mainstream. The idea of connecting computers to machine tools or large displays with light pens or tablets to augment design and manufacturing tasks was no longer something you saw in university research labs, it was something your could purchase from various vendors selling specialized hardware and software. IBM had a division chartered to create hardware as well as secure agreements with partners that developed software to support these applications. My role in this value chain was to identify needs my clients had that existing products to fulfill. The awful reality about this situation was oft times there was not a single product that could solve the customer’s issues. Thus became the journey through a more complex process of systems integration and marketing.
Most of the time I was called upon to design –today its called architect– a solution using Commercial off the shelf (COTS) components and integrate these into a solution. As the desire for the company to replicate and sell these solutions increased the term architect in its various forms became popular. My role was morphing daily from working hands on with the technology to the more abstract world of design and influencing. While I would not call myself the most dynamic and impressive of speakers –canned presentations are not my strong point– I became one of a stable of people called to present at conferences and to executives. My specialty and almost trademark in these sessions was the almost complete lack of slides. I’d bring a few slides that had the topic, a diagram and my and the account team that called me in backgrounds to make them comfortable. However, my basic approach was an empty whiteboard or flip charts which initially drew puzzled look upon client’s faces expecting a canned presentation and a sales pitch at the end. I’d start with asking questions rather than telling them my answers to issues that were more subtle and complex than what the team had identified. I would take my audience through diagraming the various issues and activities needed to be supported through to component block diagrams of a solution that would address these needs. While the sale that would eventually occur, might include all the same components, what occurred during these sessions was that the solution became their solution. Taking them through the thinking process got them to realize how the problem was solved and personalized it. The design was no longer a vendor pitching his/her wares but a partnership between all to design and build the solution.
Today, I see many professionals brought in to pitch preconfigured solutions and it an age where time to value is paramount so any shortcut is appreciated by both sides, there still exists the problem of not connecting or one would say influencing the customer your solution is the correct one for them. Often this takes the form of multiple presentations to various stakeholders, then a request for an economic justification, then finally a request for proposal and possibly a sale or a sale for your competitor. The bottom line you convinced the customer of the need to solve the problem, but not that you could solve the problem.
This harsh reality is one I have seen play out often in the field and back at various HQ positions where I’ve put together methodologies that guide** practitioners on how to design and influence the creation of solutions for their clients. I have purposely switch from the term customer to client as it is my belief that having a client orientation verses a customer orientation is a key component to success. Customers are transaction, fairly impersonal; buy what’s in the box. Clients buy capabilities and trust (relationships) that together you’ll solve problems in a mutually beneficial way. While the industrialization of consulting is occurring, so too is the problems this causes: complexities due to patching together components with disregard to the first, second, third, etc. order consequences which surface as other problems [ Probably why I joined the Center for Understanding Change www.C4UC.ORG ].
**I use the term guide as these methodologies should be trail markers not railroad tracks that don’t enable the freedom to adjust to local conditions