Vendor Briefing Instructions
We’re occasionally contacted by vendors (or their PR agencies) trying to pique our interest in their latest product, service or solution. We love hearing about new stuff, but we have some strict guidelines.
We believe in shipping products and public documentation. We’re not interested to hear what your vision is if it is not materialized in a shipping product. We don’t want to hear where you’ll be in a year. We don't care who your founders are, what they did in their previous life, or who they know to get the funding. Some of the best companies out there were self-funded from the revenues they got from paying customers... resulting in products that solved actual customer needs as opposed to being an awesome sales pitch that never worked beyond PowerPoint. There are analyst firms out there interested in that sort of information (Gartner comes to mind), but we are not one of them. Please don’t offer me a chat with your CEO, get me in touch with your engineers.
What we love to hear is how your technology works in a shipping product, and how our subscribers and customers could use it to solve their problems (not the problems vendors love to talk about). I'm not so hard to reach that you'd have to offload the job to a PR agency... and if the marketing associate working for that agency sends me a press release sprinkled with tech buzzwords after I ask for technical details we are done for good. Oh, and we don’t believe in PowerPoint but in product documentation.
We consider public access to design guides and product documentation to be the ultimate goal, but we also understand if you’re not ready for that step yet… but if you cannot provide us product documentation with no strings attached then you’re obviously not yet at a stage where we could start considering how your offering could help our customers.
Don’t even think about asking to sign an NDA to get briefed, get access to your documentation, or do anything else. Embargoes are OK and I rigorously respect them, but it makes absolutely no sense to waste brain cycles trying to figure out whether a particular bit of information was revealed under NDA, gleaned from public documentation, or found somewhere on the Internet. Two startups made that mistake, and I haven’t mentioned them for years just to be on the safe side.
Whitepapers are not product documentation. While whitepapers might be useful to get some of the nuances, we always start with product documentation.
Then there's the pesky question of pricing. You might be a brick-and-mortar company selling boxes on golf courses and that's perfectly fine, but if you pretend to be a hip company using freemium model for your downloadable software then you should have your pricing easily accessible online.
It's perfectly fine to have manual processes for corner cases, but if there's no standard pricing on the web and the only way to get a quote is to fill out a form we really don't have to talk. It's 2021, not 1989, and if it’s easier to find how much it costs to send a satellite into space than how much your license costs, you’re doing something wrong.
One last detail: we believe you're representing a networking vendor, and we firmly believe all networking vendors should be able to spell IPv6 in 2020. If we cannot reach your web site over IPv6 we consider that a huge red flag. If you can’t be bothered to spend 10 minutes fronting your web site with CloudFlare or someone similar don’t expect me to invest mine into understanding whether your technology makes sense.
Still there? Please:
- Send us a link to your product documentation;
- If we find it interesting we’ll be in touch, and will have tons of questions for your engineers;
Finally, a day has only 24 hours, and there are so many other things to do, so we might not have the resources to properly evaluate your product, in which case we prefer not to do it rather than doing you a disservice.