Oracle AI Apps for Manufacturing - Customer Feedback during Strategy Council at Oracle MBX Event

Driving product strategy starts with listening to the customer. As the PMM for Oracle AI Apps for Manufacturing, I spearheaded the Strategy Council at Oracle MBX—an open-forum event where key customers shared direct feedback and strategic needs. Afterward, I published a deep-dive blog breaking down our key learnings, participant highlights, and immediate product priorities. The blog was post originally located on oracle.com here, but now is archived on archive.org here.

 

SIEM vs SOAR illustrated via the Tesla App

In IT security, the terms SIEM (Security Information and Event Management) and SOAR (Security Orchestration and Automated Response) sometimes causes confusion or are used interchangeably. A recent notification on a Tesla App will help to illustrate the differences.

On the Apple Watch, the owner received a notification from the Tesla App that they left the trunk open on their Tesla:

So let's map this to cybersecurity terms.

Tesla detects the trunk is open and notifies you → in the cybersecurity world, this is done by  SIEM

1. It monitors the state of the system.
2. It detects an event ("trunk left open").
3. It alerts you.

Tesla app lets you tap a button to close the trunk → in the cybersecurity world, this is done by  SOAR (because human is needed to press the Close Rear Trunk button, this is the human in the loop version of SOAR)

• The app is enabling a response.
• In cybersecurity, SOAR goes a step further by automating the response or guiding it through a predefined workflow

In conclusion - using everyday experience of the Tesla App informing the owner that the trunk is open and allowing them to close the trunk remotely - this example can be mapped to cybersecurity SIEM versus SOAR:

• SIEM: "Your trunk is open." (Detection + Alert)
• SOAR (human in the loop): You tap Close Trunk. (Response orchestrated through the app)
• SOAR (fully automated): If the trunk has been open for 5 minutes and no one is nearby, the car automatically closes it and logs the action. (Automated response)

Techniques in Punchy Writing

Techniques for Punchy Writing 

In response to "California Pizza Kitchen founder says California has become too difficult for entrepreneurs",  I wrote "Florida insurance rates causing a storm of protest".  What writing techniques am I using?

1. Pun / Wordplay (primary technique)
• The word "storm" has a double meaning:
• A literal storm, evoking Florida's hurricanes.
• A figurative storm, meaning a large public outcry or controversy.
• This makes the headline more memorable and engaging.
• Example : "I used to be a banker, but I lost interest"
2. Metaphor
• A "storm of protest" is a metaphor for an intense wave of criticism or complaints.
• It doesn't mean there is an actual storm made of protests.
• Example : "Life is a rollercoaster"
3. Allusion
• The headline subtly references Florida's association with hurricanes, even though it is discussing insurance rates.
• This creates an immediate connection between the state's weather risks and its insurance market.
• Example : "He is no Romeo"
4. Emotive
• "Storm of protest" suggests widespread dissatisfaction, making the issue sound significant without explicitly quantifying it.
• Example : " Terrified employees face a heartbreaking holiday..." as the ruthless tech giant slashes thousands of jobs.
• 
  
5. News Style (Concise)
• It compresses the cause ("Florida insurance rates") and effect ("storm of protest") into a short, punchy headline typical of newspapers.
• Example : " ... as the ruthless tech giant Oracle slashes thousands of jobs."

In conclusion, writing a short punch headline requires a combination of elements that include 1) uses pun to play with word  2) uses of metaphors to find parallels in life  3) uses of allusion reference to already known people or events 4) emotive to trigger emotional response in the reader 5) conciseness because readers often exhibit TR/DL.

How Jira Lost Its Way (And How We’re Saving It in 2027)

Software project management is not about aesthetics, marketing buzzwords, or endless feature lists. It is about one cold, hard truth: delivering software predictably.

To do that, a team needs to track exactly three things: 1) What needs to be fixed (bugs and technical debt). 2) What needs to be enhanced (feature iterations). 3) What needs to be introduced (new, net-greenfield features).

Every single item in this trio requires a clear owner (who will do it) and a hard commitment (by when will it be done). This is the core, unvarnished function of Atlassian Jira. It is why Jira became the industry standard.

But let’s be honest about what happened.

The SaaS Renewal Trap

For years, Jira was a solid, highly configurable, easy-to-use tool. But as the industry shifted fully to a SaaS subscription model, a dangerous pressure took hold. In a world where customers renew every month or year, software companies feel a relentless itch to justify their subscription fees. Product teams are forced to prove they are "improving" the platform with every single sprint.  

Software Advice

This pressure created a toxic pattern: Breaking what already worked: Flawless, muscle-memory navigation pathways were suddenly hidden behind redesigned, clunky UI overlays. Fast-loading, utilitarian screens were replaced by heavy, slow-loading pages bloated with white space. Adding features nobody asked for: Or at the whim of the product manager.  Instead of mastering core ticket routing, speed, and clean sprint planning, Jira began introducing adjacent features and widgets that turned the product into a bloated solution looking for a problem.

Jira stopped focusing on helping developers ship code, and instead focused on justifying its own release notes. The tool we used to coordinate engineering became the very source of engineering drag.

Fast Forward to 2027: The Era of Judicious Releases

We heard you. The feedback from developers, product managers, and release engineers has been loud and clear: Stop changing things just to change them.

We are fundamentally shifting how we build and deliver Jira. Moving forward, Atlassian will be highly judicious with what we release. We are putting an end to the "forced experiment" era of SaaS.

Every new update, UI change, or feature rollout will now be strictly categorized into two clear, transparent buckets:

1. Must Adopts

These are non-negotiable updates. However, we will only slap the "Must Adopt" label on changes that directly improve speed, security, infrastructure stability, or core issue-tracking reliability. No more unexpected UI overhauls masked as mandatory updates. If we force an update on you, it's because it makes your daily standup faster, your queries snappier, or your deployment integrations more stable.

2. Try It and Tell Us

Want to try a new AI-assisted spec writer, a colorful roadmap visualization, or a new collaboration layout? They will live here. "Try It and Tell Us" features are strictly opt-in. They will remain hidden behind an admin toggle until they are thoroughly battle-tested by actual development teams. If the community tells us a feature is bloat, we throw it away. We will not pollute your workspace with solutions looking for problems.

Returning to the Core

Jira’s job is to get out of your way so you can answer three questions: What are we shipping, who is shipping it, and when is it landing?

By simplifying our release philosophy, we are stripping away the noise of the SaaS feature mill and returning Jira to what it was always meant to be: the reliable engine of predictable software delivery.