How to Be a Good DevOps Vendor
This article is intended for everyone involved in buying or selling tech, not just tooling vendors. The goal is to paint a picture of what an efficient supply and acquisition process in DevOps looks like. Most of this article will be phrased from a us (acquirer) to you (supplier) perspective, but out of admiration for all.
Developers, Site-Reliability Engineers, Testers, Managers...please comment and add to this conversation because we all win when we all win.
MP3: https://soundcloud.com/paulsbruce/how-to-be-a-good-devops-vendor
[embed]https://soundcloud.com/paulsbruce/how-to-be-a-good-devops-vendor[/embed]
I'll frame my suggestions across a simplified four stage customer journey:
Note: As you read the following statements, it may seem that I bounce around talking to various group in a seemingly random fashion. This is actually a result of looking at an organization through the customer lens across their journey. As organizations re-align to focus on delivering real value to customers, our paradigms for how we talk about "teams" also change to include everyone with a customer touch point, not just engineering teams.
1. Make It Easy for Me to Try Your Thing Out
(Product / Sales)
Make the trial process as frictionless as possible. This doesn't mean hands off, but rather a progressive approach that gives each of us the value we need iteratively to get to the next step.
(Sales / Marketing)
If you want to know what we're doing, do your own research and come prepared to listen to us about our immediate challenge. Know how that maps to your tool, or find someone who does fast. If you don't feel like you know enough to do this, roll up your sleeves and engage your colleagues. Lunch-n-learn with product/sales/marketing really help to make you more effective.
(Sales)
I know you want to qualify us as an opportunity for your sales pipeline, but we have a few checkboxes in our head before we're interested in helping you with your sales goals. Don't ask me to 'go steady' (i.e. regular emails or phone calls) before we've had our first date (i.e. i've validated that your solution meets basic requirements).
(Product / Marketing)
Your "download" process should really happen from a command line, not from a 6-step website download process (that's so 90s) and don't bother us with license keys. Handle the activation process for us. Just let us get in to code (or whatever) and fumble around a little first...because we're likely engineers and we like to take things apart to understand them. So long as your process isn't kludgy, we'll get to a point where we have some really relevant questions.
(Marketing / Sales)
And we'll have plenty of questions. Make it absurdly easy reach out to you. Don't be afraid if you can't answer them, and don't try to preach value if we're simply looking for a technical answer. Build relationships internally so you can get a technical question answered quickly. Social and community aren't just marketing outbound channels, they're inbound too. We'll use them if we see them and when we need them.
(Marketing / Community / Relations)
Usage of social channels vary per person and role, so have your ears open on many of them: Github, Stack Overflow, Twitter, (not Facebook pls), LinkedIn, your own community site...make sure your marketing+sales funnel is optimized to accept me in the 'right' way (i.e. don't put me in a marketing list).
Don't use bots. Just don't. Be people, like me.
(Sales / BizDev)
As I reach out, ask me about me. If I'm a dev, ask what I'm building. If I'm a release engineer, ask how you can help support your team. If I'm a manager, ask me how I can help your team deliver what they need to deliver faster. Have a 10-second pitch, but start the conversation right in order to earn trust so you can ask your questions.
2. Help Me Buy What I Need Without Lock-in
(Sales / Customer Success)
Even after we're prepared to sign a check, we're still dating. Tools that provide real value will spread and grow in usage over time. Let us buy what we need, do a PoC (which we will likely need some initial help with), then check in with us occasionally (customer success) to keep the account on the right train tracks.
(Sales / Marketing)
Help us make the case for your tool. Have informational materials, case studies, competitive sheets, and cost/value break downs that we may need to justify an expenditure that exceeds our discretionary budget constraints. Help us align our case depending on whether it will be coming out of a CapEx or OpEx line. Help us make it's value visible and promote what an awesome job we did to pick the right solution for everyone it benefits. Don't wait for someone to hand you what you need, try things and share your results.
(Product)
Pick a pricing model that meets both your goals and mine. Yes, that's complicated. That's why it's a job for the Product Team. As professional facilitators and business drivers, seek input from everyone: sales, marketing, customers!!!, partners, and friends of the family (i.e. trusted advisors, brand advocates, professional services). Don't be greedy; be realistic. Have backup plans on the ready, and communicate pricing changes proactively.
(Sales)
Depending on your pricing model, really help us pick the right one for us, not the best one for you. Though this sounds counter-intuitive to your bottom line, doing this well will increase our trust in you. When I trust you, not only will I likely come back to you for more in the future, we'll also excitedly share this with colleagues and our networks. Some of the best public champions for a technology are those that use it and trust the team behind it.
3. Integrate Easily Into My Landscape
(Product)
Let us see you as code. If your solution is so proprietary that we can't see underlying code (like layouts, test structure, project file format), re-think your approach because if it's not code, it probably won't fit easily into our delivery pipeline. Everything is code now...the product, the infrastructure configuration, the test artifacts, the deployment semantics, the monitoring and alerting...if you're not in there, forget it.
(Product)
Integrate with others. If you don't integrate into our ecosystem (i.e. plugins to other related parts of our lifecycle), you're considered a silo and we hate silos. Workflows have to cross platform boundaries in our world. We already bought other solutions. Don't be an island, be a launchpad. Be an information radiator.
(Product / Sales / Marketing)
Actually show how your product works in our context...which means you need to understand how people should/do use your product. Don't just rely on screenshots and product-focused demos. Demonstrate how your JIRA integration works, or how your tool is used in a continuous integration flow in Jenkins or Circle CI, or how your metrics are fed into Google Analytics or Datadog or whatever dashboarding or analytics engine I use. The point is (as my new friend Lauri says it)..."show me, don't tell me".
(Sales / Marketing)
This goes for your decks, your videos, your articles, your product pages, your demos, your booth conversations, and even your pitch. One of the best technical pitches I ever saw wasn't a pitch at all...it was a technical demo from the creator of Swagger, Tony Tam at APIstrat Austin 2015. He just showed how SwaggerHub worked, and everyone was like 'oh, okay, sign me up'.
Truth be told, I only attended to see what trouble I could cause. Turns out he showed a tool called Swagger-Inflector and I was captivated.
- Darrel Miller on Bizcoder
(Sales / Product)
If you can't understand something that the product team is saying, challenge them on it and ask them for help to understand how and when to sell the thing. Product, sales enablement is part of your portfolio, and though someone else might execute it, it's your job to make sure your idea translates into an effective sales context (overlap/collaborate with product marketing a lot).
(Product / Customer Support)
As part of on-boarding, have the best documentation on the planet. This includes technical documentation (typically delivered as part of the development lifecycle) that you regularly test to make sure is accurate. Also provide how-to articles that are down to earth. Show me the 'happy path' so I can use it as a reference to know where I've gone wrong on my integration.
(Product / Developers / Customer Support)
Also provide validation artifacts, like tools or tests that make sure I've integrated your product into my landscape correctly. Don't solely rely on professional services to do this unless most other customers have told you this is necessary, which indicates you need to make it easier anyway.
(Customer Support / Customer Success / Community / Relations)
If I get stuck, as me why and how I'm integrating your thing into my stuff to get some broader context on my ultimate goal. Then we can row in that direction together. Since I know you can't commit unlimited resources to helping customers, build a community that helps each other and reward contributors when they help each other. A customer gift basket or Amazon gift card to the top external community facilitators goes a long way to gaming yourself into a second-level support system to handle occasional support overflows.
4. Improve What You Do to Help Me With What I Do
(Product / Development / Customer Support)
Fix things that are flat out broken. If you can't now, be transparent and diplomatic about how your process works, what we can do as a work-around in the mean time, and receive our frustration well. If we want to contribute our own solution or patch, show gratitude not just acknowledgement, otherwise we won't go the extra mile again. And when we contribute, we are your champions.
(Product)
Talk to us regularly about what would work better for us, how we're evolving our process, and how your thing would need to change to be more valuable in our ever-evolving landscape. Don't promise anything, but also don't hide ideas. Selectively share items from your roadmap and ask for our candid opinion. Maybe even hold regional user groups or ask us to come speak to your internal teams as outside feedback from my point of view as a customer.
(Product)
Get out to the conferences, be in front of people and listen to their reactions. Do something relevant yourself and don't be just another product-headed megalomaniac. Be part of the community, don't just expect to use them when you want to say something. Host things (maybe costs money), be a volunteer occasionally, and definitely make people feel heard.
(Everyone)
Be careful that your people-to-people engagements don't suffer from technical impedance mismatch. Sales and marketing can be at booths, but should have a direct line to someone who can answer really technical questions as they arise. We engineers can smell marketing/sales from a mile away (usually because they smell showered and professional). But it's important to have our questions answered and to feel friendly. This is what's great about having your Developer Relations people there...we can nerd out and hit it off great. I come away with next steps that you (marketing / sales) can follow-up on. And make sure you have a trial I can start in on immediately. Use every conversation (and conference) as a learning opportunity.
(Product)
Build the shit out of your partner ecosystem so it's easier for me to get up and running with integrations. Think hard before you put your new shiny innovative feature in front of a practical thing like a technical integration I and many others have been asking for.
(Development / Community / Marketing / Relations)
If there is documentation with code in it and you need API keys or something, inject them in to the source code for me when I'm logged in to your site (like SauceLabs Appium tutorials). I will probably copy and paste, so be very careful about the code you put out there because I will judge you for it when it doesn't work.
(Marketing / Product)
When you do push new features, make sure that you communicate to me about things I am sure to care about. This means you'll have to keep track of what I indicate I care about (via tracking my views on articles, white paper downloads, sales conversations, support issues, and OPT-IN newsletter topics). I'm okay with this if it really benefits me, but if I get blasted one too many times, I'll disengage/unsubscribe entirely.
Summary: Help Me Get to the Right Place Faster...Always
None of us have enough time for all the things. If you want to become a new thing on my plate, help me see how you can take some things off of my plate first (i.e. gain time back). Be quick to the point, courteous, and invested in my success. Minimize transaction (time) cost in every engagement.
(Sales, et al: "Let's Get Real or Let's Not Play" is a great read on how to do this.)
At often as appropriate, ask me what's on my horizon and how best we can get there together. Even if I'm heads-down in code, I'll remember that you were well-intentioned and won't write you off for good.
NEXT STEPS: share your opinions, thoughts, suggestions in the comments section below! Or ping me up on Twitter@paulsbruce or LinkedIn.
[wonderplugin_slider id="1"]
More reading: