Sharing roadmaps with Shape up

Planning months into the future to generate a roadmap makes me feel uneasy. It’s the commitment and expectation. The mental tax is costly. It’s my understanding Shape Up advocates for working on the next most important thing each cycle instead of a planning and generating a roadmap.

People are asking me for more visibility into the product plan. I want to provide a snapshot and areas we’re interested in going next, but not with the next 3 quarters planned out. I came across this interesting post from RJS https://public.3.basecamp.com/p/6USxPaFVn2M6D7M3VyErr7BW. Started pulling on a thread to see if similar concepts could yield something I could show people instead of a roadmap.

This is what I spiked. It’s pretty much the same as what RJS has above but more closely aligned with Shape Up.

You’d show the product as an actual map. And overlay Shape Up stages to give a snapshot of today. the blue dot would be the closest thing to indicate where we’re going next.

Then you’d click the dot for more detail.

Not sure if this would even be useful in the same way. But, I like this idea of this is what’s in the cycle + here’s where we’re thinking about going next based on the current state of the world. In the RJS post above I like there being some idea of demand (feedback, ideas, support tickets, etc) mapped to the product area as well. Would need some way to represent that here. E.g. “the Embed Widget is swelling with demand we should go explore that next.”

How are people using Shape up + a roadmap? Or, how do you provide visibility into the future for people outside of product?

8 Likes

Hi Tony, same challenge here. How do we communicate the product roadmap to our leadership? there is an interesting post here by Ryan. He suggests to treat feature roadmap as a list of options to be evaluated. Instead of communicating milestones and try to line up a roadmap, just show your stakeholders what options do you have on the table. In our team, we had a fair conversation about this with our stakeholders and customers and they were ok. I would also suggest to involve them in discussing each option so that you can understand what is perceived as the next important thing to do.

2 Likes

Hey Tony and Fabrizio,

I really appreciated your posts. I’m curious to know what approach either of you might take when communicating your roadmap to external stakeholders (i.e. customers)?

Historically my company has shared roadmaps of varying granularity (e.g. here’s what we’re targeting over the next 2 quarters) with strategic clients. That doesn’t seem to jibe with Shape Up.

While I love these alternatives for internal use, I don’t think sharing a map, or a menu of options would sit well with customers. Of course, I’m also wary of commitments and the expectations that come with a more traditional roadmap. I feel like there must be some mystical other way.

Any thoughts are much appreciated!

@samsles Shape Up was designed for product companies. When you’re a product company, customers buy what you already made. Selling something that you didn’t make yet belongs to a different type of business model: the solution shop, where you build custom work for clients.

1 Like

Hey @samsles we start sharing with customers when we’ve committed to the work and it’s kicked off. At this point we put it on a public page for customers updates.launchnotes.io under in planning (bet on, setting scopes, and discovering work) or in development (building the slices). Full disclosure this is the product I work on.

The distinction here is that we’re communicating with customers “what’s on the way” VS. roadmaps which are “this is where we expect to go in the future.” We feel ok sharing publicly once we’ve kicked off work because our implementation of Shape up starts to diverge here – we don’t make use of the circuit breaker. I’m learning if this modularity of shape up adoption bricks the whole spirit or not.

We found people looking to share extra info with “strategic” clients/customers can get pretty far with simply sharing what’s currently being built and what’s on the way. At a product company someone paying you $999/month vs $19/m may be more interested in what to expect from product development. The 3 distinctions here with external stakeholders are:

  1. Knowing what’s coming,
  2. Sharing a roadmap
  3. Letting strategic clients/customers set your roadmap

As a product company we do 1, but not 2 and 3. Hope that helps.

1 Like

Thanks for the responses, Ryan and Tony!

Ryan, we’re not doing custom work for clients, but rather looking to convey “where we’re headed” with the product as it relates to outstanding requests. This practice may be incompatible with Shape Up as there is no notion of a backlog.

Tony, your approach is very similar to ours. Given that we’re not circuit-breaking projects either, I’ve been communicating what we’re actively working on with confidence. The problem is our big customers want to know “what’s next” because they tend to submit specific requests and want to gauge if/when we are planning on addressing them. I’m not sure how to break our organization of this practice if that’s even possible. BTW, I just checked out LaunchNotes and would love to learn more as we’re currently in the market for a better solution to notify customers of product updates :slight_smile:

1 Like

Hey Samsles,

I think I noticed a small contradiction in what you’ve said and might be worth reflecting if what you say matches up with what you do…

we’re not doing custom work for clients

vs

they tend to submit specific requests and want to gauge if/when we are planning on addressing them

If I’ve misinterpreted any of that, then never mind. But thought it might be worth considering :slight_smile:

Hey Aylon, that’s a fair interpretation. I should clarify that my definition of custom work is contract work. I.e. work undertaken for a specific customer, with a specific budget or timeline parameters.

As a practice, we don’t guarantee that any customer requests will be addressed, but we do take those requests into consideration when deciding what to work on next. For instance, it’s possible that we identify a common thread for multiple requests and feel that we can address them all with a project that aligns with our objectives as a company.

Given that Shape Up is predicated on commitments that are, at most, 6 weeks into the future, it may be that a roadmap that extends beyond this is fundamentally incompatible.

1 Like

Hey @samsles, I think your situation resonates with a lot of software companies.

On our team (B2B marketplace), I saw absolutely no issue with using Shape Up while also having a roadmap that we loosely shared with customers, e.g. on the phone or in emails.

We looked at what e.g. Janna Bastow recommends with “Now / Next / Later” buckets that contain strategic themes more than actual features (although these make it in there as well, sometimes), alongside Rich Mironov’s recommendation of clearly labeling the decreasing certainty that is attached to those buckets (high to low). Personally, I’ve gotten the most out of what Rich writes on roadmaps and was able to apply some of the other techniques he mentions (like the Sales Silver Bullet).

This worked well both internally and externally, as far as I was aware. I don’t think Shape Up particularly stresses that one shouldn’t have any idea for the future direction of a product, but just leans heavily on the notion that you shouldn’t be making commitments further out than six weeks. As long as your style of roadmapping aligns with that, I don’t see any issues.

1 Like

Hey David,

These are amazing resources, thanks for sharing! Rich’s slides resonate deeply with our situation. I’m going to look into creating a roadmap of decreasing clarity as well as distributing the responsibility of managing scarce resources with our Sales Team.

Also, greetings from another Product Manager Parent :wave:

1 Like