This message was deleted.

By "suggestions", I mean, can you suggest ways in which to communicate our long-term vision and goals without being overly specific. I have a clear idea of where we need to go in the short and mid-term, but I don't see a lot of value in scoping out work that may be irrelevant in 6 months

Write a one pager describing the world, treat it like a startup pitch deck

+1 to both suggestions. try to articulate the vision, the value add

You can probably be 3m specific and 18m vague

try to provide a 3-6 month roadmap with 80% confidence, 6-12 month roadmap with 50%

Hah yeah

that’s probably where i would stop

Also challenge constraints - buy buy buy if you have a team of two and are supporting that much surface area, roadmap can include vendors etc. most people never think to include that bc it’s always framed as “us personally are building”

if you are going to that level of depth, you should be sharing your views on most meta topics. e.g. “release cadence”, “support model”, etc

Awesome suggestions, thanks Andrew and Jordan! I think the idea of writing up a one pager to craft the narrative, with a few supporting slides is really helps. I was initially trying to build up a Miro board to describe the roadmap in a single graphic, but I think its hard to capture the context and nuance that way

Miro can always be a supporting artifact that individuals can “double click” into if interested. i would consider those deeper explorations

I’d add that it’s important to tailor this message to the audience. If this is going to “leadership” then you can talk about the goals your trying to achieve, rather than how you’re going to get there. In technology, we have a habit of telling leadership what we’ve achieved after the fact. Pretend you’re a start up - make some wild claims about what you could achieve in 3 years if the company adopts your ‘vision’ … and then of course, you need to talk about having a budget commitment of 3 years. When your leadership all inevitably go silent at that point, you can then wheel out your 3-6 month agile plan that lets them try first, get some wins and build iteratively. 😉

You could try the “now->next->later” format. This gives you an option to be precise about current execution and strategic and coarse for the future - without the need to explain the format or content-depth yourself, as you can point people to the definition 😉 Also, engineers at the receiving end of your roadmap will probably already know how to read it and understand the implications of the buckets. https://www.prodpad.com/blog/invented-now-next-later-roadmap/

I feel there’s often a strong tendency to bias towards listing a bunch of solutions on roadmaps with that time horizon. Which is where I find problem-based roadmaps can be useful, especially on this timeframe, by focussing on the challenges you’re going to solve and face, as opposed to how you’re going to solve them. Quite likely that the solutions will change and adapt, but far less likely that the problems will just go away on their own accord 😛.

Three years seems like a really distant future, especially for a team of two, but maybe this is a blessing in disguise because it will help prove the value of what your small team is trying to achieve and may even help justify growing your team (if you think that's appropriate). I definitely agree with the recommendation to focus on the business value of what you're work does. It may help to start with the end in mind: if your team was wildly successful, what would that 3-years-hence future look like for the business and your developer customers? How would you measure how that future was better than today? Without knowing anything about your company's current practice, hypothetically: Would lead time be reduced to a few days? Would the IDP platform have a > 80% uptake? Working backwards from there, do you have mechanisms to capture this information today? Does every team build their own private data store with varying quality or security concerns? Do you need to build tools or foster adoption to get instrumentation in place in order to be able to measure the improvement over time? Once you have some idea of the end state and major objectives, you can probably identify some fundamental things that have to be done first, then fill in the middle with large blocks of time (3-, 4-, or 6- months) for major themes, and almost never have to be specific about any particular technology.