2017 R&D
At the last staff meeting we talked about some of the threats and opportunities we are facing this year. I wanted to expand on that and on what I see as critically important product development for this year.
One of the threats we talked about was getting squashed by big competitors. Salesforce continues to invest in their 'community cloud', Zendesk built something, Verint bought Telligent, Sprinklr bought GetSatisfaction, Lithium is fighting back and has stolen two customers from us in 2016 and has a broadened its product offering, etc.
How much longer can we survive as a best of breed point solution? Probably a bit longer but it will get harder and harder.
When looking at widening our offering we can buy, build or partner. The first critical important item on our roadmap is the partnership opportunity with Hootsuite.
- They have social media management, we have community forums.
- They have 3 instances of Vanilla (one for support, one for ideation and one for advocate marketing) and see the value in what we offer.
- They have a sales team of 160 people and a growing enterprise business that is competing with many of the companies mentioned above.
- We have access to their senior leadership.
Strategic partnerships don't really get better than this. Hootsuite's enthusiasm and support will not last forever and we have to act right away to get this implemented. @Linc I would like to see items related to this integration in every sprint from now on and a launch before end of quarter. This is a top priority.
The next area that lets us broaden the product and where there is clear customer demand is support for static content: basic blog articles and a knowledge base articles. We hear time and time again, especially from customers looking to come over from Lithium or Jive. These prospects are unwilling to implement Vanilla along side a second product such as Wordpress because it means buying two products instead of just one and so we must build it ourselves. Based on what I've heard from customers, a V1 that is very limited in terms of features is all we need to get started.
I read an interesting analogy for minimal viable product (MVP) the other day: If a customer's hair is on fire and they have absolutely nothing on hand to put out the fire, you could sell them pretty much anything that would help, for example a brick. If they buy a brick, you know there is a real problem and you can then work on a better solution such as a bucket of water. When we push into new areas, it's ok to go market with something limited based on a preliminary understanding of customer needs and not worry about covering every use case until we get some traction and customer feedback.
Static content gives us an entry into the 'knowledge management' space and would let us position Vanilla as a more robust product suite: Forums, Knowledge Management, Ideation, and Q&A.
The third critical priority, in my opinion, is to spend some time on innovation that will put us back in the product leadership position that we used to enjoy but that has been fading as new competitors emerge and as others catch up. I don't want to downplay the features, infrastructure and refactoring that we've done lately, it's cutting edge development that has allowed us to close millions of dollars of revenue. I think this year we need to work on our opening act, bring some new razzle dazzle to the product.
The idea that is floating around is an AI feature. Sure, it's a trendy buzzword and overhyped but I think it's a worthwhile path to explore. The idea sounds very doable and might actually be a great feature. Here is my rough understanding on how it would work:
- Community forums become knowledge bases with time. People love self-serve support and so how do we make it easier to find an answer from the community knowledge base?
- Today, you can post and wait, you can browse or you can search. A good search result requires a good search query, well written discussions a good search engine, etc. Can we put an AI on Vanilla to do a noticeably better job at answer someone's questions?
- We'd run all posts through an AI (an NLP service) that tags content with concepts, the AI can make abstractions and identify concepts that aren't directly referenced in the text. This is what makes it a lot better than keyword search.
- Users can ask questions, the question is run through the same NLP, and comes back with an answer based on matching the concepts in the question and in the community content.
- I'm not sure what the UI/UX looks like: Does it look like search? Is it interactive? Is it Tim's Minion?
- NLP services like Watson have become commoditized and are sold on a per transaction basis, we do not need to build our own and we don't incur big upfront costs for the NLP engine.
- I'll stop here since I have a feeling I'm botching the explanation of this idea and will let Todd and Tim expand.
This AI feature fits very nicely with the knowledge management story and will be easy to market if we are the first in our category to deploy.
Last thought for today. I don't feel that we did a great job marketing our new product features in 2016. Let's find the right balance between thought leadership and product marketing on our blog, email marketing, and webinars.
Looking forward to your feedback.
Comments
-
I agree with you Luc on things getting harder in driving demand. We have more and more competition and now imitators on the very go to market tactics we've used to distinguish ourselves from the rest.
Last thought for today. I don't feel that we did a great job marketing our new product features in 2016. Let's find the right balance between thought leadership and product marketing on our blog, email marketing, and webinars.
This feedback is noted. Having a formalized process where roadmap items are clearly communicated well in advance, along with a product marketing launch plan is critical. We've found ourselves often "surprised" with deployments in the first part of 2016. Things have gotten better but a longer-tail cycle of:
-Calendar of planned releases with set meetings between marketing, dev and product owner.
-Technical Release notes
-Product marketing driven:
--Webinar for customers (quarterbacked by CSMs for all important customer attendance)
--Blog announcements
--Perhaps a release notes section dedicated to the product on the website (docs or otherwise)As long as there is time alotted for each of these steps, we can easily execute on the marketing side.
1 -
As far as new feature priorities, I'm generally on the same page. I think jumping straight to "AI" when we don't even have basic "related content" or "recommender" systems is a little too ambitious, but I've been doing my own noodling with community-oriented bot that can tie multiple channels together (chat, forum, social) and I think there's a lot of compelling brainstorming room there.
That said, our R&D bandwidth is incredibly constrained and many of our bread-and-butter functionalities need serious attention this year. I don't know how to plan a roadmap with that level of ambition given where we're starting the year. The foundational work necessary to accommodate much of this has been repeatedly punted down the road in favor of reworking the product for short-term sales. I don't think it was the wrong choice, but now we have some consequences from it to address.
Vanilla's core advantages are:
- Single Sign On
- Integrations
- Themeability
Two & three need serious maintenance work, namely 1) an internal API to lower the barrier for new integrations & training time for new devs, and 2) a new base theme with parent/child theme relationships to lower the cost / dev time of new themes & training time for new devs. Lithe (Mobile 2014) is now a maintenance anchor around our ankles on a web that has largely moved on to responsive design.
What we're doing now in these two areas cannot scale in a meaningful way; even doubling our services devs would not double our capacity here on any useful time scale. We're in a deep hole and still digging with each passing month we ignore these things.
Vanilla's core workflows are:
- Reading & Posting
- Moderation
- Onboarding
Again, two and three need serious rethinking. People cite our moderation features as a key reason they chose us, yet we haven't meaningfully added to or improved that feature set in a long time. A centralized moderation workflow that allows for multisite integration is near and dear to our existing customers' hearts.
If our onboarding were half as good as Facebook's, we'd have amazing stats to share with potential customers about user conversion & retention. We haven't even photocopied their low-hanging fruit features in this area. Meanwhile they found time to roll out Reactions to the entire Internet while our thousands of open source users still don't even have it 6 years after we invented it. If we've dropped basic table stakes feature parity to the ugly global cesspool of a Facebook group, we're weakening one of our most central marketing themes: own your community.
In 2016, we added two major code bases:
- Analytics
- Dashboard v3
Both are big wins for us. But whenever we do this, we add to our pile of maintenance and need for ongoing enhancements. I can never put either of those projects "to bed" ever again - they are now going to need attention in every quarter, if not in every sprint, forever. Adding a person to the R&D team in 2016 is the only reason we could keep our heads above water while we did this - and these were code bases that either mostly stand apart from our core forum framework (Analytics) or mostly replace an existing code base (Dashboard - albeit now more complex). If we're prioritizing new highly integrated code bases for a Blog, a Knowledge Base, AND some AI/NLP components in 2017, I probably needed two more developers to have started their onboarding about 3 months ago.
What happens the day after we ship a MVP blog or knowledge base? We'll have 30 issues left from development, 30 more will be opened via support in the first month, and we'll immediately get customization requests and "Well we'll sign if you just add Y" opportunities ad infinitum. If we're treading water now, that maintenance cost will be what puts us under water, not the build cost.
Vanilla's dev team has always had a "do more with less" mantra. These competitors we talk about - from pure-forum Discourse up to publicly-traded tool suite Lithium - have developer teams that are 3x our size or far larger. Discourse hired more people than we have on our entire R&D team in the last year or so. To operate in those constraints, I cannot understate the importance of extreme, dire care being exercised in how we add new features. We are forever dancing on the precipice of support & maintenance costs eating our entire team.
My top priorities coming into 2017 were:
Rework our product to use an internal API that can have proper automated testing applied. In the medium- to long-term this will seriously reduce developer support costs, increase stability / reduce deploy incidents & time costs, and let us create integrations with less upfront AND less ongoing resources. Everything that comes before this increases our product fragility & support costs in ways that may soon become unsustainable.
Rework our theming to use a modern, responsive HTML & CSS foundation, adding a parent/child theme relationship to maintain backwards compatibility with our existing themes. This will seriously reduce our customer onboarding costs, our support costs, and the cost of adding new features.
Beyond that, I wanted to see our moderation workflow redesigned (including a federated multisite queue) and improve our Sphinx support to start moving in the direction of AI-like features baked into the product. Tagging, Profile Extender, and Reactions all need to be baked into core to operate as a scaffold for the rest of our ecosystem. Every one of these things is a multi-sprint project that either blocks or vastly helps speed up future efforts for a dozen other awesome new things we want to do.
These are all things we've known we must do to get where we want to be for well over a year. But, they're not sexy enough. Every time we think we're about to finally get there, we have to rework some huge part of the system to support a new client or do an emergency feature to onboard someone: ideation, category scaling, permissions refactor, and so on. Delaying the work doesn't make it go away, it makes it worse. And, far more insidiously, it makes it harder to hire and train new developers.
When I wrote a new roadmap document for 2017 I tried to make it less of a feature checklist and more of a statement of values and priorities for how we decide what to do next. I could summarize it as: Great support, low churn, maximize resources, and steadily grow the platform. The points laid out here check all those boxes. Prioritizing shiny features first given our current resources will do the opposite of all that.
Our R&D team is running like a well-oiled machine now, but it's pulling exactly as much weight as it can, and 2/3 of our effort is going into support & maintenance, directly or indirectly. I understand we can't put the team in a monastery for 3 months to crank out a new API, but the flipside of that is that we're even further constrained until we start hitting checkpoints with it.
I thought early Q2 for Hootsuite was highly ambitious if we want to deliver an integration that won't break three times before the end of the year without us even knowing it - because how would we ever know unless it's built on an automatically tested API? We have to deliver a jsConnect v2 in the next month to address a security issue (including migrating everyone using jsConnect to the new system), there's on ongoing line of Dashboard and Analytics fixes and enhancements, we still have 30-some backlogged security issues from 2015, and if you give me an important bug ticket today we're stacked so deep on support I can't get it fixed until February already.
We're spinning 28 plates in the air and I feel like instead of using the 1 free hand we have left to build a stand to hold them all we just wanna see if it can spin 5 more plates. 2017 is the year we're gonna start breaking plates if we don't get serious about this stuff and stop talking about our roadmap without mentioning the elephants in the room.
There's no one who wants Vanilla to have more awesome features as quickly as possible than me. I start my every day reading forums, moderating them, and dreaming up how I wish they worked better. When I got bored over vacation, I started tinkering again. But I also have my feet closest to the fire here and things are going to start smoking pretty quickly if the primary marching orders for 2017 are to land a 747 in a field when we're still mixing concrete for the runway.
And you know I'm serious when I cram two metaphors in one sentence. :chuffed:
I think it could make good business sense to prioritize one or more "suite" offerings (blog, KB) ahead of reworking some of our core workflows given the current environment. But, I think those core workflows are far more important than splashing out into uncharted territory like AI. And before any of this happens, we need some serious API & theme work to free up resources (and take a hard look at whether we can invest in additional team members) or we're not going to get to any of that without an abysmal churn rate.
I can get preliminary spec work for Hootesuite into the next sprint. From there, we can evaluate how much of the API we need access to to complete the work in a reasonable way. It will mean shelving Analytics again and likely some support tasks. Maybe jettisoning the warp core.
I'm giving 'er all she's got.
6 -
Not for nothing: Announcing a CMS suite is when I knew vBulletin had lost the plot and it was time to look for new forum software. When it was time to double down on updating their core product & code base, they went for breadth and made terrible me-too features instead by basically grafting it alongside the forum code. I'd bet they made more sales in the short term, for all the good it did them.
This fear nags at the back of my brain, always. We still have a tiny team. Tiny teams need to focus on their core competency or they will be surpassed. The very fear of our larger competitors is what will make us spread ourselves so thin we can be beaten.
2 -
@Mel said:
We've found ourselves often "surprised" with deployments in the first part of 2016. Things have gotten better but a longer-tail cycle of [...]I agree, and I look forward to talking more with marketing this year. I think we did really well on the Dashboard release and I think it set up a nice framework for making that work better moving forward. And, we're reworking our VIP & 4xx release schedule to accommodate this workflow better.
0 -
After speaking more with Luc and reviewing things further, I've updated my Trello board o'projects for 2017. This order & item selection isn't set in stone (it's literally a kanban board) and we typically work on 2-3 things at a time. Red is for Blockers, yellow is for Expected. There's obviously more to the board as well; I just guesstimated with where I cropped it.
I want to emphasize I'm not promising all of this can be done by the end of the year, this is only for internal reference, and this list isn't exhaustive. I use a simple kanban board instead of a Gantt chart for a reason: we're flexible, and giving timelines months in advance is just a pack of lies.
Also for the R&D team: the assignments are pure guesses too. I'm still spit-balling how this plays out. Keen to hear about what you're interested in working on.
5
