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) Launch Server Side (Beta)
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. Launch Server Side gives you a place to define rules that will run on Adobe's Edge Network instead of on your page. 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) Audit Events 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.
1) Discontinue extension packages
Extension developers will be able to mark a particular version of an extension as "discontinued". This will prevent that extension package version from showing up in the index calls and in the catalog. This will not remove the extension from any properties where it has been installed, but it will prevent installation on any new properties. This provides recourse in case of security or privacy issues with particular extension versions and also allows developers to gracefully end support for extensions if needed.
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) Biggie-size name fields
Sorry, we should have done this a long time ago. We're going to make the field lengths bigger.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.