Simply copy and paste the following command line in your terminal to create your first Strapi project.
npx create-strapi-app my-project
I was hired by Strapi in November 2020 to join as the first salesperson. And it was quite a challenge! First of all, even though I had acquired technical knowledge through past experiences, I didn't know a thing about CMSes. And a headless one, even less! ;)
One of the reasons why I accepted their offer was for the opportunity to build a Sales Team from scratch. That being said, within a company mostly made up of developers, it could have been a cause for concern:
And that's completely normal. Software engineers traditionally do not like salespeople. The article "How Technical BDRs Can Play A Key Role" from Decibel VC also gives additional insights on this topic, and I am aligned with their vision.
However, Sales & Engineers can be the best of buddies, and here are our top 3 principles for an effective alignment.
There is one thing I have always enjoyed: spending time with the tech team, spending "a day in the life" with consultants, participating in technical training, and testing my skills with practice tests...
And, most of all, being hands-on: having a sandbox where I can play! Lesson learned: do not forget to shut down the managed Hadoop cluster. Otherwise, you'll receive an email from your CTO in the early morning, true story!)
This sort of behavior is fundamental to legitimizing your recommendations and succeeding in convincing your customers to adopt your solution. Selling is not the end game. It should only result from your efforts to position yourself as a trusted advisor and product specialist rather than a "sharp knife".
Gratefulness comes mostly from two things:
First of all, Respect the product: developers have their way of building a product, and after shadowing a few kick-off / stand-up meetings, I can assure you that their backlogs never get empty. Compromises are made according to the right value they need to deliver at a specific time, so it's also the salesperson's responsibility to understand these trade-offs, commit to the choices made, and support the decisions in front of prospects/customers.
For the record, when we launched the Content Internationalization feature, my first reflex was to think: "A language is only a variation of content... So we could trick that feature to create custom/fictive languages to build workarounds for features such as A/B testing!" Yeah, but no. As a salesperson, you should always be creative and solution-oriented, but never forget to submit your ideas to the Product Team so they can verify them from a technical perspective. TL/DR: it wasn't a good idea ;)
another example ;)
Hey Devs, I just wanted to say that I love doing my job every day because I love the product I sell!
Secondly, the Time. I want to shout out to all the devs who take the time to explain the product to us salespeople. Most of us aren't good at reading documentation, watching tutorials, or even looking at Stack Overflow threads. We even struggle when filling out the information in the CRM, how do you expect us to do that?! (I'm joking, ofc).
I often do quick sessions with my buddy, Maxime Castres, Growth Hacker, who guides me on how to get into a terminal, how to install a JSON viewer add-on, how to do simple GraphQL queries... Every time, it's a small victory. Every one of those moments is much more valuable to me than signing a deal. Every additional piece of technical knowledge I acquire thanks to developers, is one more step to enhance the closing rate of my deals' pipeline.
Software Engineers tend not to be the most demonstrative people (but it's nothing compared to my bunny 🐰 👇 , he doesn't care at all),
But please be aware that every person working in a Sales position has a bit of an ego. That's a positive thing! Showing gratefulness to your Sales teammates is the greatest compliment they could ever receive. It's like the ultimate approval from your Sensei.
My teammates spend an incalculable amount of time building an awesome product, and they rarely get the chance to see how the community uses it to solve so many problems. And when you're an awesome person building an awesome product, you should expect awesome outcomes.
That's why salespeople should always take the time to share a few sentences, a screenshot, a comment... or whatever it is that gives Developers a real idea of the final usage of the product. We're sharing more than feedback here. It's about transmitting daily inspiration and positive vibes to other people. It's like being a route to the API config. 🤓
At Strapi, we consider feedback a gift, and the #feedback Slack channel has at least one message per day.
Still, field experience feedback can hardly be considered actionable since it doesn't rely on exact data, a requirement for product-decision making. If you ever feel that way, remember that it's not just about giving precious insights; it's about creating as many 'Ahh, that's nice to read!' moments.
On the other hand, a best practice all engineering teams should follow is to open a "cross-team hub". A place to share the goals, decision-makers, functional scope, timeline, dependencies, and information to get ready for a successful release. It's even more useful when you're working on a highly technical project like the refactoring of your query engine ;) Thus, you're empowering Sales (and not only them!) with a vision.
Thanks for reading this article! And if you feel aligned with it, Strapi has job openings both in Sales and Developer positions ;)