As the Adobe Experience Platform has evolved, so has the Launch team and our place within the Platform. Our portfolio has expanded beyond web and mobile - and now includes Launch Server Side, the Edge Network, the Web and Mobile SDKs, and a bunch of other exciting things. Our team has welcomed new product managers and engineers. Our managers have been given new teams to manage. All with the goal of making it as easy as possible to gather data from client devices and send it wherever you need it to go - Adobe and otherwise. To reflect this expansion of our scope, we have put together the Data Collection Roadmap to provide broader insight into the things we're working on. Roadmap updates will be posted on the new page. We'll leave this one here for the archives and bookmarks.
When the Launch product team receives a feature request, we need to weigh it against all the other things we could work on. I'm going to describe the general approach we use on the Launch team. And then I'm going to tell you what we're working on.
When determining priority, several factors weigh in, but the two that tip the scale most are:
Impact on the user/company: When assessing the impact, we ask questions like how big of a deal is this? Does it make new things possible or existing things more convenient? Is there a security impact?
Reach: This is an estimate of the number of users/companies impacted. This is relatively straightforward, but here we're deciding if this is - or will be - a common request or if it's an edge case that probably only applies to a few users.
These two things are balanced against one another. A project with a small-ish impact for hundreds of customers will probably take priority against a project with a significant impact on two customers. We include Ideas in the Community as candidates along with others that we feel are important.
At any given time, we'll have one large project, one medium project, and several small projects running in parallel. We make sure that the large project is fully staffed - moving as quickly as it can, then the medium project, and then as many small ones as we can until we run out of manpower. We determine size with a SWAG of how much time the project will take in terms of 2-week sprints.
Small projects should take less than one sprint
Medium projects take 1-3 sprints
Large projects take more than three sprints
When we finish a large project, we'll take up the next one - in priority order. Same for the medium and small projects. Generally, this works out to 3-5 projects going at any given time. 1 Large, 1 Medium, 1-3 Smalls.
Taken together, Priority and Size are the main factors that determine where something lands on the backlog. With that in mind, let's go ahead and take a look at the Launch Backlog. Two preliminary words of caution before you read this list and start to mentally assign delivery dates to features based on size and priority:
These are not the only things we're working on - they are just the most visible. We also spend a lot of time and effort on system security, stability, and maintainability. We do integrations with other Adobe product teams that don't reflect specific feature improvements. We fix bugs. All of which is to say that we're working on these things, but this is not necessarily the order that they will be delivered.
Priorities are always shifting as we respond to changes in impact, refinement in size estimates, business conditions, and many other factors. Just because it's a priority today does not guarantee it will be one next week. We try to minimize this, but things happen.
Those two items notwithstanding, we've received enough requests for a public roadmap that we decided to give it a try - don't make us regret that decision. We will update this list as priorities change, and as we finish the items on it, so you should always see two large projects and four medium projects.
Happy tagging 😃
1) Edge Network access for All
Builds (especially big ones) often take a lot longer than we want them to and the minification could be improved. We're working on a new compiler that we expect to bring significant improvements in both areas.
1) Biggie-size name fields
Sorry, we should have done this a long time ago. We're going to make the field lengths bigger.
2) Extension Developer tool enhancements
We need to make some improvements to the toolset we provide to Extension Developers to enable them to build extensions for Launch Server Side.
3) Audit Event filtering
To date, audit events in Launch aren't particularly useful. Launch generates a lot of them - for valid reasons, but they're hard to parse. We don't provide great tools for filtering, searching, or narrowing them down. And there are also limitations around how many can be displayed within the UI. We're planning on fixing all of that.