From the other side, this looks like "management signed up for some flashy product based on marketing, but it turned out to be useless". Not recognising that seems like a substantial blind spot.
It would be interesting to hear from anyone who evaluated Cord and decided not to use it. I wonder if the risk that the company might fold entered into the decision.
Still, excellent of them to have open-sourced it; it superficially looks like they've put a lot of effort into making it usable.
It’s more likely literally what the author says - getting engineers onboard for something they themselves didn’t choose is difficult. I’ve been in the same position - lots of buy in from leadership / solving a real problem and providing real value. Then it takes months to implement due to having to corral a dev team who simply doesn’t care about your integration.
Due to the software culture I've been exposed to, especially in web-dev, I am cautious about any level of indirection added by third parties. They may seem like a value-add to first-order, but when managed in the context of a larger system, tend to make performance worse, debugging more difficult, and modifications high-inertia. Not as a principle, but based on observations.
For example, When I see text like this: > With pre-built components for chat, presence, and notifications, as well as fully customizable UI primitives, Cord enables rapid implementation of sophisticated, in-app collaboration tools.
my pattern-matching brain thinks This is probably going to be slow, require the user to download a large amount of data, and may or may not reduce code required to implement, and will make customization and modification tedius. Maybe this isn't true for this particular library, but it seems to be a good rule, currently.
Devs: It sucks ass.
We would have a senior dev on the dealing-making-or-breaking call and he would say something like, "Wait -- sorry, do you support <specific thing that our system doesn't have>?" We would say honestly that we don't have that yet. Then the senior dev would say, "Ooohh.... sorry... yeah... we need (per-message arbitrary data storage | support for on-prem | real-time analytics | per-messsage privacy controls | etc.)." We eventually had to face the reality that one of two things must be true:
1) The market is just too fragmented such that there cannot exist one product that serves it
2) The devs involved really, really don't want to give a product like this a chance because they actually want to build fun features like this themselves and they're (rightfully) skeptical that some random startup can do it better
As I sit here now, I have some confidence that it's 75% #2 and 25% #1. Anyway, the basic shape of the sales calls went a lot like what you're saying.
If you think most engineers are evaluating things based on the value it’ll drive for their product, you’ve lived a lucky career (and long may it continue).
Management wants to add Google ads to their premium offline app? Sure, they'll work to add that, who cares. Whether they spend two months building this feature or another, they're getting paid the same amount.
I get the context here (you are talking about software engineers, fine, and adding silly chat features, which is pretty low stakes). But, still, want to mention the general case:
The engineer’s professional obligation is to push back against the company if they are asked to design something impossible (and try to find some alternative that fits the customer’s business need if that’s possible), and to refuse or possible whistle-blow if asked to do something unethical/harmful to society.
We live in a very corporatized society where professions are being turned into jobs left and right. But, the engineer’s job is to just implement management’s requests in the same way that the doctor just exists as a conduit to your insurance company: that’s the way the company would like it.
Some features are annoying to work on, some have long term implications for how much and what type of work will need to be done. Some just don’t fit with what the engineers want to work on. I know which features are going to take endless stakeholder meetings and which aren’t. I know which are going to require overtime and being on-call. I know which are going to kill off my pet project.
The most self-serving action a software engineer who doesn’t want to work more than the bare minimum can take is to reject as much as possible as being too difficult or bad or some other excuse.
What usually happens in my experience is that management comes up with some new requirements that they may or may not have already sold to a customer on a more or less specific timeline. They then ask for an estimate on when that will be implemented in the product.
If the estimate doesn't conform to their expected timeline, they typically challenge it vehemently. If you can convince them that it's a realistic estimate for what they're asking, they then start discussing ways to reduce the scope while still delivering more or less the same feature. If you can't, then it will end up at "you're being pessimistic, let's start and we'll pull through", which will later turn into "we'll have to work this Saturday because we're way behind on what we committed on that feature".
Sometimes, a very well respected engineer will occasionally be able to convince someone in management that a feature is just not worth it. But that is the rarest case I've seen, and it will definitely not happen if some junior or middle engineer tries to invent some generic excuse.
As a loose analogy paper trading can work great as practice(and if done right is supposed to help with this). Yet when u apply your system and stuff goes sideways, you're sweating and emotionally(as well as financially) impacted for real now, not just on paper. Those losses are real and paper trading would never 'hurt' like that.
That's one way to look at it. Usually though, for upstarts, what's paramount is not the profits part, but the risks inherent in working on a solution for a perceived problem (or worse, for customers one is ill-placed to sell to [0]). I like what Seibel recommends: the v1 must solve an acute problem for the customer to pay up [1]. From there, building out a holistic product may put our upstart on path to growth & profitability while simultaneously expanding the scope of the problem space building such a product brings [2].
[0] https://www.michaelseibel.com/blog/users-you-don-t-want
Great insight.
Like, it's not clear to me what problem it solves.
It's described as "The complete SDK for Chat, Commenting, and Notifications" yet I've read the entire readme and it isn't clear which languages it has client-SDKs for, if any.
If my boss came to me and said, "Can you evaluate Cord for a chat and notification back-end" I'd return a quick message ruling it out on the basis of there being no documentation, no example integrations, no obvious client SDK packages, etc.
It's also hardly zero-friction just getting it running. It needs both Node/NPM and docker.
Why? Either ship me the NPM packages, or point me to a docker command I can run. If it's containerised, why does it need NPM? If it's shipped as NPM/source, why does it insist I deploy with docker?
Show me some simple code examples so I can see how easy it is to get a chat client running, don't give "broken" links to docs and APIs that would only work if I'm already running your software, I'm unlikely to get that far without browsing the API and docs.
Think Figma comments as a service. Examples of it in production: https://www.workcanvas.com/
There are still 3-rd party sites with copy of the docs, like https://docs.comment.workcanvas.com/ (full of dead links), but it seems the main site used to be "cord.com" and this is already sold to some job search site.
I am surprised they did not open source the doc... or maybe no one has bothered to bring up the server?
> We're becoming cord.com
> Hi,
> Over the next few weeks cord.co is becoming cord.com. Adding an "m" to the end of our URL is one of the smaller things we've done. But it represents something much bigger: that cord has become the trusted source for tech hiring in the UK.
Docker is used to setup the db, cache, and aws emulation.
https://github.com/getcord/cord/blob/main/ops/docker-compose...
There were times I sold a product that the users (Dev Team in the author's case) wanted desperately, but leadership (VPs of Product, CPOs, PMs in the author's case) didn't see the importance and/or urgency of. And yes, there were times when I sold a product that leadership wanted desperately, but users didn't see the importance and/or urgency of.
The second case can be wrangled over user objections, but in the long run, such products end up failing once past harvesting the Hawthorne Effect. The lasting successes were the ones where all the stakeholders (I know, I know, buzzword alert) bought in.
And that's why closing Enterprise Sales is a load-bearing role in an Enterprise Software business. It's hard to do, but through a combination of product design that creates discoverable value for every "buying influencer" (another term of art from sales) and needs discovery on the part of sales and product management, followed by tailoring pitches and demonstrations for each group, you can get them all in a room nodding together and close the deal.
It is NOT easy. And a lot of this is not the vendor's fault. Beneath the superficial appearance of a recalcitrant dev team, there may be scars from previous top-down dictated changes that did not, in fact, do anything for the users or the company, so closing a deal may involve a lot of listening and empathy and a very open mind.
People make fun of Enterprise Sales as a perfectly coiffed salesman golfing with the customer's CIO, but the hard truth is that Enterprise Sales is hard because Enterprises are full of people with complicated needs and relationships and perception and the entire thing is steeped in hidden historical legacy context.
I feel for the author, I really do. But I also reflexively feel for the customer's dev team. And for the customer's leadership. A change to communications tooling is a change to a load-bearing part of a company's processes and culture.
Selling this kind of thing is not easy.
Yes I do, here's one that is very well-suited to startups who want to sell to the enterprise: Product-Led Growth ("PLG"). This is defined as building a product and customer acquisition strategy around people trying the product for themselves and then buying the product without interacting with a human.
To make this work, you have to strategize which feature or features will close people using the product, as opposed to leaders looking at a PowerPoint with estimated ROI numbers. You have to make them discoverable, and you have to find a way to surface the value to users... In the product, not in a white paper or on a marketing web site.
You also have to have someone own PLG and ruthlessly experiment with user experience design and product design to drive better and better PLG. Yes, you have to track it and prioritize it.
PLG can't be your only strategy, you still need Enterprise Sales. For most enterprise products, PLG will never generate as much revenue as sales. It will be tempting to ditch it as wasteful compared to just building whatever the C-Suite demands from salespeople. BUT!
If you have any traction at all with PLG, your product will also be an easier enterprise sale. The problem the author listed is greatly mitigated by a product that has even modest success getting individuals and/or small businesses to buy it based on their trial experience only.
PLG can be the key to unlocking enterprise revenue, you just have to play the "long game" with PLG and treat it as a particularly honest way of obtaining user feedback, which must be coupled with a mechanism for improving the product based on that honest feedback: Someone must own PLG, must be held accountable for driving PLG, and they must have enough authority not to be swept aside by prioritizing top-down features.
I can see this being a tough market.
One - it's a crowded field, with many solutions in each of those three categories. I don't think we've actually come across Cord while evaluating solutions, which just shows how noisy it is.
Two - I struggle seeing "chat / commenting / notifications" as a unified category. Every project we've worked on had unique requirements for each of these (whether justified or not...) so every implementation ended up being different.
It's definitely a pain to roll out these features from scratch, and we always preferred using something off-the-shelf where possible.
But by the time you finish evaluating options, pick one, implement and customize it, deal with its limitations and bugs - plus projecting several years of usage costs, and uncertainty dealing with an outside vendor - I can easily see how the balance might tip to doing it in-house in many cases.
Not trying to armchair quarterback - I know how hard startups are, and respect to the Cord team for being in the trenches! Just sharing my experience.
Look at the comments under the first one, lol
https://www.reddit.com/r/ProgrammerHumor/comments/14xljje/yo...
> import thefuckisthis
> printf("this meme format is garbage, please promote your site in some other manner");
> return downvote
At the time we were rather surprised when suddenly, seemingly out of nowhere, Cord popped up as a direct competitor to our product. We were even more surprised to find out that, only a few days after we learned about them, they had discontinued.
I just gotta say that not everything the author shares resonates with me. Notably the idea that devs really really want to code chat and commenting from scratch. Our customers generally have plenty of competent developers on staff, and these devs all have plenty to do and generally they just don't want to waste time building an entire WhatsApp clone inside their platform/marketplace/tool/whatever. They'd rather spend that time working on unique features for their market instead.
We do, however, need to convince developers that they can control everything they want to control. If they get only the the slightest idea that we're either bullshitting them or simply not letting them build what they want to build, the conversation is over right away. I suppose this holds for any product that sells to devs though (or one that sells to PMs but is, in practice, vetoed by devs).
I still don’t get this obsession that startup founders have with “memes”. Like I get it, everyone loves internet jokes, but when I hear CEOs use the verb form and talk about it like it’s a core strategic practice (this seems to be commonplace among founders who like Elon) it has a strong ring of “How do you do fellow kids?”
You are painting the adoption problem as the software team having a different opinion on the build-or-buy decision. It could be they were OK with "buy" but didn't like your product for other reasons.
You've said that management teams liked the idea of your product, not that engineering teams liked working with your product. All software these days is built on stacks of OTS software. Of all the external dependencies they took on, why was yours different?
I've been on a bit of a tear recently, throwing away internal tech from 5-15 years ago that was inventive at the time, but where high quality off the shelf solutions now exist. I've still skipped on number of things I've wanted to pull into our stack. But they're too opinionated when they should be stupid libraries or flexible external services. I can't reshape our existing software to fit their idea of how our product can make life easier for them.
eppp•6mo ago
IggleSniggle•6mo ago
Wilduck•6mo ago
I don't think that's totally fair in this case, since it seems they open sourced their software. But also, in general, I think NIH syndrom gets a bad rap. Sometimes a "worse" solution you control really is more reasonable compared to a technically superior solution made by an external company.
eppp•6mo ago
hobs•6mo ago
Every quarter during budgeting I have politely pointed out this inferior service costs us a lot of money and sucks at support as well, and every time its considered not a priority.
Today its a priority :)
nailer•6mo ago
eppp•6mo ago
echelon•6mo ago
That certainly hasn't ever happened to us before.
Every external { tool, vendor, SaaS, platform } is a potential risk. You don't want to eat a year of unplanned costs and a quarter or more of engineering hours of migrating off.
JackFr•6mo ago
IggleSniggle•6mo ago
saghm•6mo ago
IggleSniggle•6mo ago
saghm•6mo ago
guappa•6mo ago
riehwvfbk•6mo ago
tsimionescu•6mo ago