VRBTM Initial Marketing | Week II

Wes Jones
VRBTM
Published in
8 min readOct 2, 2016

No one seems to get our positioning and what we did about it.

Not sure what this is, start here with our README, and catch up with Kicking Off Verbatim | Week I.

Sunday, September 25, 2016

Nick and I met up at the Ace Hotel today so we could work together. New York is deceivingly absent of good, free, places to work. The colleges don’t want anything to do with you if you’re not a student, and the New York Public Libraries are closed on Sundays — who knew?

Anyway, The Ace Hotel is prime and I expect we’ll be back.

Initially got down to business to discuss timelines so we have something to work against. We’re making progress, but we need a date to be accountable to. Looking to have the initial working prototype up by October 16, with a more polished MVP that we’ll push out in early November, likely the 6th. Followed by consecutive two week feature sprints after that.

We’ve detailed the baseline prototype features that need to get in there, and then once that’s up we’re going to sit down to blue sky everything else that we’d like or need to implement. This will include some more polished design and a feature-set that will clearly position us a part from the other content transfer services out there. While our six months out monetization milestone is still a ways off, we’re thinking about it now with the decisions we’re making as it will certainly play a role when we give priority to our roadmap.

Need to research the nuances that make agreements binding and how they’re enforced. Finding that the law in the USA is pretty encompassing here.

With the October 16, prototype date, and November 6 MVP date I can start putting together the initial marketing plan for the next month. Nick and I talked about it and this is what it’s going to look like.

  1. Identify start up bloggers and various start up web communities.
  2. Start publishing our weekly drafts to the VRBTM Publication on Monday, October 3, 2016.
  3. Submit to BetaList ($129) so that it goes live next week. 10/3–10/6.
  4. Follow up on those forums and identified bloggers with our live BetaList page and Publication.

BetaList doesn’t let you submit to their platform if you have a live product, so we’ll only have our splash page with an email sign up form. We’ll be using that list to send updates on development and beta access to the product. I need to edit some of the design on the splash page and make sure the copy is exactly as we want it.

Following that we think we can get a spike in traffic again in November when the public MVP rolls out. After which we’ll target Product Hunt and Hacker News. If we could get picked up by TechCruch, The Verge, Mashable and LifeHacker that would be great for us this early on but not expected.

One of the nice things about working next to each other is that any questions we have can be immediately answered or discussed. Neither of us are trained designers, but we work around it enough that for now we can get away with doing it ourselves. Overall the design aesthetic is to be very lightweight, but with that, it means each decision has to be carefully considered. Every design choice so far has been to remove as much as possible and place a lot of emphasis on the things that remain.

We’re setting up a Slack channel to keep our conversations in one place. I’m going to ask Nick if he’d be into using a project management software so we can track against our deliverables. I’d like to go with Flow which I’ve used before.

Setting up Slack
Set up Slack with a few integrations so that we get all of our notifications in one place instead of flooding our emails. Already it’s been a great way to keep tabs on everything with very minimal effort.

Marketing
Installed the Mailchimp integration for when new users sign up to our email list along with Twitter for when people tweet at us.

Build
Made a separate channel just for the GitHub integration that tracks commits, pull requests, and other activity. We talked about an error tracking integration, but at this point we don’t think we need one.

Wanted to keep this separate from the development channel where we’ll just be discussing the code base and deliverables as opposed to updates.

Stripe
Once we have a paid offering, we’ll integrate Stripe for user sign ups and payments, each in separate channels.

Support
Added the Zendesk integration to trigger an update anytime a new ticket or follow up comes in.

Sendgrid or FileStack
Was hoping that either of these would have a Slack integration so we can have an alert when someone is using the free platform but neither of them do. Not the end of the world as the Sendgrid iOS app has a nice dashboard of reports which will work, though I would like to keep everything consolidated.

Wednesday, September 28, 2016

Really need to take a look at the splash page. Figured we should test the language before submitting to BetaList as I expect we probably have 10–15 seconds after someone lands to capture their attention, understand the value proposition, and be intrigued enough to provide us with their email.

It’s a lot to ask in a short amount of time, so we need to make sure everything is working to increasing sign ups. Volume is the key metric here.

To find out where we stood I sent the page out two a few people who hadn’t seen it before to get their initial opinion.

Two of my friends don’t get it at all, and my dad just says to call him.

Great.

Not the responses I was hoping for.

Each of my friends made comments that they didn’t get what it would be used for, or what it actually would be doing, and asked for more of an explanation. Which, when I explained it they completely got it and saw the value immediately. Leading me to realize the copy isn’t working hard enough, if at all, to convey the message we need it to.

Calling my dad I pretty much expected having to explain it to him as I ended up needing to with my other friends which would validate that the page needed to be re-worked. However, he answered and went right into how he saw the platform working, the value it brought, and even explained how it could work in other industries — absolutely nailing everything everything we need people to get from the page. At least someone got it.

Still, while that was good, only a 33% conversion rate isn’t nearly enough. What I realized from this small test was that while Nick and I can look at the page and understand the value proposition and selling point, we can only do that because we have the perspective of the whole platform and the solution we are working to provide. Without that context it’s now clear where the confusion comes from. Everyone who comes to the page as it stands would have to read through the feature points and then create their own narrative for how it would work for them. Way too much to ask for.

The initial splash page with all of the info, but no story.

To fix this, I’m going to rework the copy with an illustrative use case that gives the reader a situation that they could adapt and see themselves in. Therefore surfacing the problem and creating a desire for a solution.

First up, changing the tagline to A Content Approval Platform. It’s not my favorite as it’s very straight on, but it now answers the What is it? question. The first ever tagline was One Platform. Fully Automated. which I still like, and maybe will come back around at some point.

More direct, but still not everything.

Instead of three feature headlines, I’m going to draw it back to one, Manage all types of content Verbatim. Alluding to the fact that any piece of content can be sent verbatim: photos, video, text, etc. — Actually now that I see it on the site I’m taking this out.

Still, no one knows how to use it yet, or what value it will bring.

Landed on: Effortlessly send any type of content verbatim for review, feedback, and approval. All managed in a single dashboard where every approval is backed by a binding contract.

Used verbatim as a verb to begin seeding the idea of each piece of content sent on the platform should be called a verbatim. Added the any type of content bit and brought up the review, feedback, and approval process. It somewhat feels like it’s saying the same thing as before, but this process outline should give the reader a jumping off point for whatever their ‘any type of content’ is. Then ending with the value prop that everything is contained in one dashboard, and most importantly each approval is treated as a binding contract.

Now, the page weight is off. Going to flip the explainer text and the sign up form along with adding Launching November 2016 under the sign up. Much nicer now, and is certainly about as minimal as you can get.

Hard to edit something you think was already working well. Though there is a stronger narrative and it’s actually done in fewer words overall, which should help in our 10–15 second window. Also, if people aren’t getting the purpose served with this, they probably don’t have a use for the platform anyway and if they bounce out, no worries here. Need to start writing a longer paragraph explainer.

Read the other half of this week with Nicks VRBTM.CO Development Stream | Week II.

We’d love to hear from you…
Get in touch at Founders@vrbtm.co, talk with us on twitter @vrbtm.co, and read our story on medium.

Wes Jones is on Twitter @WesJonesCo
Nick Dandakis is on Twitter @Dandakis

Join our email list for Beta access.

--

--