On Roadmaps and Selling Stuff You Haven't Built Yet
You've been invited to attend a hugely popular conference where your company's COO (who you adore and respect) is giving a keynote in front of a thousand people plus more watching the livestream from home.
They get halfway through an inspiring presentation about how your software helps people do their jobs better when they click over to a slide of…
I've never seen THAT dashboard view in our app before…
"…and that's why I want to introduce you to <insert some fancy new name for a feature that hasn't been built yet here>. With this <new feature that's basically vaporware>, all your dreams can come true…"
This, my friends, is leadership selling ahead of product.
Selling Stuff You Haven't Built Yet
In the SaaS world, it's pretty common practice for people to show off screenshots, slide-decks, or videos of features that haven't actually been developed yet.
Typically, this isn't happening on stage in front of a thousand people. More often, it's a subtle click to a new tab in a screenshare meeting or a design mock-up file that ends up as a page in a proposal.
And, it's not always as nefarious as I'm making it sound.
Sometimes companies make the decision to be transparent about the exchange, selling things they haven't built yet as an extreme exercise in product validation, i.e. "If you'll sign the contract and pay upfront, we'll build this feature you want next quarter."
If you can actually deliver in the agreed upon timeline, this isn't always a horrible thing to do.
At this point, your business is basically acting as a contractor, building custom work for one particular client.
Problems arise when:
- You cannot deliver the new feature within the timeline as planned, or
- The new feature becomes too narrow, only benefiting the one specific customer who was willing to invest in it.
When this happens, it's easy to get off course and stray from your big picture strategy and objectives.
My friend Landon wrote a bit about this phenomenon recently. He said,
"You just sort of build based on the next couple potential customers that show up. This can create technical debt and features that get neglected over time because that one high paying customer asked for it that one time."
So, how do customer-focused founders and product managers stay headed in the right direction?
A product roadmap can be a tool to remind you to prioritize development and stay true to your vision, even as you're considering specific features or work to support customers coming through the doors.
When I think about a product roadmap, the first thing that comes to mind is something like this:
In this example, the projects are organized by teams and laid out horizontally across a timeline. It's easy to visualize which projects must come first and to see when something might be released.
But, what if some of the projects take longer than planned? Would everything get pushed back?
The Gantt chart format might work just fine for managing internal operations, but it's probably not the best format to share public updates with your customers. When you see something visually presented on a timeline, it's hard not to internalize expectations about release dates, even if someone is using their words to tell you, "Take this with a grain of salt."
This past week I had a chance to check out the Pendomonium conference in Raleigh. I snapped a picture from one of the speaker presentations, because I loved the way this alternative roadmap was organized…
Here's the original tweet from #pendomonium2018.
In this roadmap format, releases roll up neatly under projects and objectives as they relate to key parts of the business strategy and larger vision.
This template is great, but it's a lot to take in! As a customer, I want to know which features will be coming out soon and also where the company may be headed in the future.
So, what might work instead?
Here's an idea… what if we simplified our roadmap template into:
- Summary of our long term company vision
- What new features are definitely coming "soon," and
- Our broader objectives for the near future.
- Coming Soon could be updated with each feature release,
- Objectives could be updated quarterly or annually, and
- Vision could be updated annually or less frequently (whatever makes the most sense).
Even as an internal roadmap doc (not shared with customers), this template could be a helpful mental framework for understanding how to answer questions from customers or prospects about upcoming developments.
Anything on staging or in beta testing should be pretty fair game for anyone to share, discuss, or even promote with screenshots or design mock-ups (with an explicit caveat that it's "coming soon"). Anything that's not on staging on in beta testing should probably only be discussed as an idea relating to an objective.
And, if, for any reason, you make a decision to sell something with design mock-ups before it's "coming soon," you should hold yourself accountable to explain why you're willing to take that risk.
When you sell ahead of your product, you pass on that risk to your buyers and also to your employees.
Early-stage employees are likely to expect and embrace risk, but fewer employees will have tolerance for this as you scale up.
So, my take is this:
If you want to sell it today, you should have built it sooner.
Plan tomorrow accordingly.