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?
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 fix bugs. We are also working on a few other things that we aren't talking about publicly yet. These things weave together, so priority does not dictate delivery.
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) Server-side Hit Forwarding
Sometimes you need to send a modified or stripped down version of your Adobe Analytics data to a third party. Sometimes, your page is dropping 30 different pixels for different marketing vendors, and your IT team is out for blood. Sometimes you need to send the same thing to three various 3rd parties. You may benefit from server-side extensions. Send your data to Adobe, have Adobe transform it, and send it along to someone else. You will manage this in Launch, but many teams will be working to bring this capability to the Adobe Experience Platform.
2) Rule Component Sequencing
3) Audit Events Overhaul
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.
1) Sitemap & Navigation
A number of suggested ideas here in the forum all really boil down to making it easier to tell where you are in the app. We're going to redo the navigation to make more working space and at the same time, make space to show you (in a breadcrumb format) where you are at all times. See the name of the rule while you are editing a rule component. When you're 3 levels deep in the resource compare, we'll show you the full path down to what you're looking at now. Hopefully you'll never feel lost again.
2) Revision Compare on Library Edit Screen
Comparing revisions is very useful, but it's not always easily accessible in the workflows were you want it. Based on user feedback, we're adding a way to initiate the resource comparison from the library edit screen so you can easily compare resource versions when you're choosing what to put into a library.
3) Extension Package Reporting API
We are building this feature for extension developers to allow them to retrieve usage metrics for their extensions. We think it will also be useful to others who would like to see information like the number of times an extension has been installed or published.
4) Search Results Page
We brought quick search to Launch at the end of last year. It lets you type in pretty much anything and find resources that match. But when you find them you don't get much context for why that particular resource matched, and the only thing you can really do with your matches is jump to them to see the detail view. The search results page will:
Allow you to see more matches
Show you what matched (name, settings, etc)
Let you filter matches by resource type
Let you choose between exact match and fuzzy match
Enable you to search within resource revisions
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.