We’re at the end of the fourth week of the new year already (kudos to anyone still maintaining their new year’s resolutions) and I hope this blog finds you well. Depending on how you navigated here you might have first stumbled across this introduction to the blog series:

When I first started this product development blog series back in 2022 and I wrote “we've got some really exciting plans brewing at AppsAnywhere HQ,” I couldn’t have predicted with accuracy exactly what we’d be developing in the first month of 2024; although I would have tried.

I’m often asked to share a product development roadmap with people. They could be our valued customers, my internal stakeholders, or a future customer that wants to understand the direction of the product to see if our value proposition is a good fit with their own technology strategy. In that respect, roadmaps are an essential part of the product development tool box.

Writing and sharing roadmaps may be bread and butter for a Product Manager, but how often to share them, and to what level of detail, and who to; that takes some thought. Plans change. But if they change frequently, and you share them too often, it can lead to confusion. So timing and context are everything.

Let’s take a moment to think about what a product roadmap is. Or more specifically what a roadmap is. A roadmap is something that helps you understand how to get your car from point A to point Z. You select what you think is the best route with all the information you have to hand at the time and you get on your way. In that respect you have a plan. But if you think about a car journey and the modern era of sat-nav, then at some point on your planned journey you might be offered (by a disembodied voice in a box) the opportunity to take another path to avoid congestion; congestion that wasn’t there before you set off. And now that you (or rather the cloud computing that sits behind the disembodied voice in the box) have the luxury of the additional data, you can adapt your plan and reap the associated benefits: like getting there earlier, or taking a more scenic route, or having improved options around when you choose to take a pitstop. You still found your way from A to Z; but the journey wasn’t exactly what you originally planned.

That’s why we at AppsAnywhere develop our software using agile principles and practices. By breaking the development cycle down into small increments, we can inspect and adapt our plan as we go; with the benefit of the new insights that we didn’t have when we first started on our path. It stops us over-committing to a route that we no longer want to follow. Our vision for the end destination remains the same, but the way we got there was not what we expected when we set off on the journey.

Breaking our development down into smaller phases is not just beneficial from a business perspective, it is a good thing to do from a customer perspective too. It means we can adapt to feedback and emerging themes quicker, without just having to drop a huge thing that we’re working on, because what we’re working on is broken down into a smaller chunk. For customers to access that benefit though, we need to release our software frequently too. But in the current world, accessing a new release means scheduling an upgrade. So that’s where our brand-new upgrade process in AppsAnywhere 3.2 will come in handy!

I’m pleased to share that for anyone on AppsAnywhere 3.1 or above we’ll be able to deliver an upgrade to the latest version of AppsAnywhere in-place. In-place upgrades will mean a faster process, with less downtime during the upgrade period, and less requirements during the upgrade window. Ultimately it means quicker access to new features. It will be more automated and simpler to perform for everyone involved. Win win!

So if you want to get your hands on the latest features, and benefit from the new in-place upgrade process, then look out for more information coming on our 3.2 release next month.