As it often happens that new technology is hard to get approved in production environment and all developers face the problem, therefore, I am curious how you guys (would) sell the Meteor as a technology stack for enterprise company. I see a lot of benefits in Meteor and think that getting the reactive datasets to the client is a clause strong enough to make Meteor to be considered as a potential technology. I have been thinking of cases where Meteor and D3 combo could be used in real-time BI solutions and so on. I think its a great showcase that Meteor can provide reactive data by default. I was thinking that maybe you could imagine yourself at client selling Meteor as a technology for new cloud product and provide here the strongest clause you can build up to sell it. Lets say that you are selling to client whose product will have anything between 10-1000 connections with authentication and the product should provide real-time chart data from MongoDB. You are selling Meteor+D3 solution, how would you sell it in a matter of fast development, reactivity, realibility, availability and scalability?
I suppose the first question you need to ask yourself is who is your audience? Is it a programmer? a CTO? a business guy? Depending on who you’re selling, you’ll need to take drastically different approaches.
When selling anything, you have to remember the majority of people “just want to look smart to their boss”. So put yourself in their shoes and ask “How will using meteor make them look good to their boss?”… is it speed? The ability to use trendy hipster technologies? Cost savings? Having a final app the looks “modern”?
For instance, if you’re selling to “business people” (who does not care about stuff like “I CAN USE REACT MIXINS, D3 and ES6!!!”), and assuming they know a little about the tech world, you can mention MDG is backed by Andreessen Horowitz and Trinity Ventures. Having an example or demo-- something visual-- may be important for them… you may want to use words like “real-time” instead of esoteric-programmer-buzzwords like “Reactive”.
If it’s a CTO maybe they’re interested in saving time & money they can bring up in the next report to the CEO. So a selling point may be saving (very very expensive) dev ops man hours by just using galaxy…savings can be pretty big if the alternative is paying someone $150/hr to wire from scratch. You may or may not want to use esoteric-programmer-buzzwords like “Reactive” rather than normal human speaking words like “real-time”.
If it’s a programmer, than maybe it’s worth talking more in-depth about the stack, using esoteric-programmer buzzwords, obscure acronyms, and similar.
You may also have to ask how important is reactivity to the BI. It seems like your post focuses mostly on that… is the need for data so time-sensitive that they can’t just refresh the screen? Is the reactivity important to the BI app or important to you because you think it’s cool?
But how many sells to one person directly today in enterprise, I assume that when talking about selling enterprise solutions to companies both parties are having quite an identical organizations sitting next to table. I mean that if you go to sell enterprise solutions for company they might have competence managers, architect, developers, lawyer etc. involved (as well as you) and in this scenario you must be able to provide very comprehensive information regarding to topics around. Organizations and methods are quite standard todays, so I think you can come clean on everything.
The enterprise culture is very different from small startups. They tend to be very old school, risk adverse and terribly slow to change because the decision makers often have many disincentives. They are usually motivated by job security and prefer choices where blame can be passed if something goes wrong.
I recently pitched Meteor to an enterprise company with a large IT staff. I started by pushing efficiency and rapid development. The CTO seemed very compelled when I mentioned how React was by FaceBook. I guess it’s easier to justify products that are used by very successful companies.
I got permission for a small test project, but it didn’t take off. Like many big businesses they were Microsoft based. Their IT people liked Windows, SQL and IIS servers. At the time, Meteor was just a bad fit.
I think the future is promising. Apollo should help Meteor break into the enterprise market. SQL server support would be a great selling point. Also native support for Linux in Windows 10 might help the developer experience in Windows which currently is lacking compared to Linux and Mac. The last step would be a good way to deploy on Windows servers. I know there has been some progress with IISNode.
It will help a lot. Because it allows them to retain their data stores. I am not sure if Apollo supports SOAP web services, because there’s also a trend to hide the legacy data stores behind web services to prevent direct access to the data. @sashko may be able to answer that.
If you want to convince the enterprise, few things you need to consider.
1, how will it work with their authentication systems?
2. can I monitor it using our existing monitoring systems/protocols? e.g. JMX, SNMP, redis, nagios?
3. what is the state of LTS for your product? If we choose version 1.3.2, am I going to expect 1.3.2.99 or do I need to keep up with 1.3.3, 1.3.4, 1.4? Do I how much new skills between versions do I need to deal with between versions not just backward compatibility but have a sane upgrade path between versions?
4. how do we manage the application deployments?
5. Disaster recovery? Large enterprises have DR environments. JEE offloads most of this to the container and let people like IBM deal with it.
6. Blame points… if something goes wrong who can we blame and to pay for any problems.
Yep, supporting existing legacy backend services is one of the main goals, and something GraphQL is quite optimized for. See how it works in real life in this blog post:
Meteor sells support like this: https://www.meteor.com/developer-support
And as of yesterday, we also do for Apollo! http://www.apollostack.com/graphql-support
I like what you are doing in Apollo project, Apollo can be quite a jackpot for you and everybody else in the field and I have no doubt it would not be as you have well detailed objectives that you are working toward, hard.
Regarding to Apollo I am like waiting for some food to be drop from table, so I can start to chew it, however its hard to me follow where Apollo is at the moment. There are blogs telling what Apollo can do and what are the objectives, but for me its on clear that where are you at right now. I hate to be a person who is asking whens dinners ready, but maybe that gives a cook extra drive to prepare the best meal 
I work at Disney, and a selling point I used was the built-in support for user accounts and authentication. I created a proof-of-concept demo with two new packages disney and accounts-disney, which were minor forks of the core google and accounts-google packages for using Google as an oAuth provider. Of course there are other frameworks that provide easy integration to oAuth or similar services like Active Directory or SAML, but with Meteor I was able to modularize it into a package that can be internally hosted and pulled into any Meteor app. Having built in-house oAuth authentication from scratch for a non-Meteor app a few years ago, being able to add it as simply as meteor add accounts-disney is a huge time- and bug-saver.
This is definitely true, but how far into the selling process are you?
It’s not likely you will call the enterprise and set up a meeting where they call in the CEO/CTO/Law department and 12 other people for your first meeting. More likely, you’ll be selling one person first… the goal being to get them to be your insider-- your “champion”. They will be the one to convince the enterprise that it’s worth setting up a meeting with 15 people to hear you out… but highly unlikely you will cold call them and have that large meeting be your first interaction.
and even if they did pull all of those people in to a single meeting, who is the most important person to sell first? Craft your message to them (even if the law team and a programmer are in the room). Then be ready to expand if and when the details get asked about by the ancillary meeting participants like law and tech (by being ready verbally and maybe with extra slides in an appendix of your pitch deck).
TLDR: (1) you will probably have to find a inside champion before you find yourself in a meeting with 12 department heads. (2) it doesn’t matter how many people are in the meeting… narrow down your most important audience member. If the CEO’s opinion holds the most weight for technology procurement decisions, aim for him. If you can’t sell him, it doesn’t matter how many legal or tech questions you are ready to answer, as you’ll be dead in the water to begin with.