Understand our buyers

Because of the size and complexity of the products we build, the typical buyer is at the C-suite level, including the following roles:

• Chief product officer (indicates organization has adopted a product mindset)
• Chief information officer (IT is tasked with delivery or this is a highly technical project)
• Chief technology officer (coming from IT, likely team undersized to deliver)
• Senior vice president of engineering (similar to the above)
• Chief digital officer
• Senior vice president (business side of business making a purchase, SVP likely responsible for a specific product line)
• Chief innovation officer (higher risk, project may be a prototype)

These people are the driving force behind technology organizations with annual budgets of over $100 million. Understandably, they are pressed for time and difficult to approach.

We also target influencers who report to the CIO, like the director of delivery, director of PMO, or director of digital banking. These folks at the director level are probably tasked with solving tech problems and are more likely to entertain a capabilities presentation. Long term, however, we need to get the CIO’s signature on the master service agreement.

Avoiding innovation players

Chief innovation officers are not on our list of buyers because we’ve found that innovation groups don’t work on products that fit our model. They’re usually focused on proofs of concept that validate new technologies for the business versus big-budget transformative efforts that span a year or two. Furthermore, the innovation teams are often siloed away from the business and have little influence on the day-to-day operations.

Addressing needs and concerns

There’s a separate section in this book about our value and positioning, but it’s worth briefly discussing some common needs and concerns we’ve discovered over time in our work with buyers in the roles above.

• They lack the internal capacity to do the work. The organizations we work with often struggle to attract and retain great people. As a result, their internal teams are focused on support work and lack the bandwidth to take on anything new.
• They lack the skill sets to do the work. Building a great product org is a challenge. Even if the client hires developers, product designers, and product managers, combining these skill sets and developing the necessary culture of trust is a challenge.
• The time to market is critical. There is pressure to get the product out the door quickly (in six months or less). Timing is dictated by the business need or a major industry event.
• They need to recover from failure. Work completed to date by a different vendor isn’t working. The organization needs to course-correct and continue building on top of the codebase.
• Partnerships as a strategy. Some enterprises intentionally hire partners to focus on product work, having recognized the skill set is challenging to develop in house. A word of caution—while seemingly an ideal scenario, the lack of internal engineering means that we rely on third-party partners for infrastructure . . . and they’re never as fast as we are.