When I visit enterprise/B2B companies to talk about agile and Venture Design, I often hear ‘Hey, this stuff is great, but a lot of what we have to do is driven by large customers. How do we handle that?’ I don’t pretend to have a silver bullet, but I do have a few practices and focal points I’ve found help drive better outcomes for everyone.
There are lots of good reasons for big customers to buy software/SaaS from smaller companies: economy of scale, focus/expertise, and the ability to bypass internal stalemates. That said, lots can go wrong for everyone concerned. The storyboard below is a little hyperbolic, but it’s one narrative I’ve seen plenty:
No one wins here. In fact, if it happens enough, you may find the big customer you so assiduously cultivated by executing on their requests switching to an alternative product with stronger direction and coherence. Ouch!
Agile (the fundamentals) can help. In particular, I like the user story as a way to anchor the relevance of what everyone’s proposing to invest in, product-wise. Peeling back the onion from there, make sure your stories anchor to strong problem scenarios and personas.
Why the personas and problem scenarios? Because design thinking is cool? They’re important because they help us make sure we know who we’re creating for and whether or not they’ll care about what we’re doing. Also, done right, these outputs should link directly to testable assumptions you can use to validate end user motivation as you go.
The stories also provide a nice focal point for phase-appropriate user testing.
Beyond these practices, there are two practices I highly recommend considering. The first is investing heavily in training and rotating the core product (or even exec.) team into those engagements. First, training is a great way to ‘indoctrinate’ the user in your point of view. For evidence of that, just look at the Cisco training program and its effectiveness in creating evangelists. If you feel like you should be out more with customers, but just haven’t found the time or project to get that going, training is a great substitute.
I also think it’s important to align your business model type with your development investments. Business model type (infrastructure vs. scope vs. product) is an important topic recently resuscitated by the business model canvas. The idea is that successful companies focus on one of these three types. In Silicon Valley, we tend to think in terms of product. However, many great business like Amazon Web Service and Twilio are actually more infrastructure-oriented (driven by scale and having lots of users/buyers doing the same thing).
If you’re getting a lot of incompatible requests for changes to your user interface, maybe it’s time to invest more in and operationalize an API/services layer or toolkit for custom front-end’s.
The slides below support a talk I do on ideas and practices in this area.
What do you think? Please get in touch and/or comment!
