Companies are spending vast sums on AI expecting the technology to boost efficiency, but a new survey from AI consulting firm Section found that two-thirds of non-management workers among 5,000 white-collar respondents say they save less than two hours a week or no time at all, while more than 40% of executives report the technology saves them upward of eight hours weekly.
Workers were far more likely to describe themselves as anxious or overwhelmed about AI than excited -- the opposite of C-suite respondents -- and 40% of all surveyed said they would be fine never using AI again. A separate Workday report of roughly 1,600 employees found that though 85% reported time savings of one to seven hours weekly, much of it was offset by correcting errors and reworking AI-generated content -- what the company called an "AI tax" on productivity.
At the World Economic Forum in Davos this week, a PricewaterhouseCoopers survey of nearly 4,500 CEOs found more than half have seen no significant financial benefit from AI so far, and only 12% said the technology has delivered both cost and revenue gains.
Microsoft releases security baseline update for M365 Apps for Enterprise version 2512.
Excel, PowerPoint, and core system settings receive enhanced protections.
These updates block risky links, insecure protocols, and legacy automation features.
Microsoft is beefing up its enterprise defenses this week with a major security and compliance update for Microsoft 365 Apps for Enterprise version 2512. This new baseline strengthens Excel, PowerPoint, and core system settings to help enterprises stay protected against evolving cyber threats.
Specifically, the latest baseline updates several Microsoft 365 Apps components, especially Excel, PowerPoint, and core system settings. These updates address new attacker techniques, customer feedback, and secure‑by‑design principles.
Excel security enhancements
According to Microsoft, File Block now includes external link files, which prevent external links in blocked workbooks from refreshing. “Attempts to create or update links to blocked files return an error. This prevents data ingestion from untrusted or potentially malicious sources,” Microsoft explained.
Blocking insecure protocols
This new security baseline also blocks all non‑HTTPS protocols when opening documents. This capability helps to eliminate unsafe downgrade paths and enforces TLS‑secure communication across apps and cloud services.
Additional hardening
Lastly, Microsoft’s new security baseline blocks risky automation interfaces such as MSGraph.Application and MSGraph.Chart. Microsoft 365 Apps will render them as static images instead to address a risky automation interface. Moreover, this baseline disables the legacy OrgChart add‑in for security reasons. It also prevents fallback to FrontPage Server Extensions RPC to ensure the usage of modern, authenticated file‑access methods.
Starting this week, administrators can deploy the security baseline via Office cloud policies, ADMX policies through Microsoft Intune, or Group Policy for on-premise Active Directory environments. Microsoft has divided the more complex settings into individual Group Policy Objects. These include policies that block Dynamic Data Exchange, legacy file formats, legacy JScript, and unsigned macros.
In preparation for our upcoming Building SaaS Businesses with AI Superstream, I sat down with event chair Jason Gilmore to discuss the full lifecycle of an AI-powered SaaS product, from initial ideation all the way to a successful launch.
Jason Gilmore is CTO of Adalo, a popular no-code mobile app builder. A technologist and software product leader with over 25 years of industry experience, Jason’s spent 13 years building SaaS products at companies including Gatherit.co and the highly successful Nomorobo and as the CEO of the coding education platform Treehouse. He’s also a veteran of Xenon Partners, where he leads technical M&A due diligence, advises their portfolio of SaaS companies on AI adoption, and previously served as CTO of DreamFactory.
Here’s our interview, edited for clarity and length.
Ideation
Michelle Smith: As a SaaS developer, what are the first steps you take when beginning the ideation process for a new product?
Jason Gilmore: I always start by finding a name that I love, buying the domain, and then creating a logo. Once I’ve done this, I feel like the idea is becoming real. This used to be a torturous process, but thanks to AI, my process is now quite smooth. I generate product names by asking ChatGPT for 10 candidates, refining them until I have three preferred options, and then checking availability via Lean Domain Search. I usually use ChatGPT to help with logos, but interestingly, while I was using Cursor, the popular AI-powered coding editor, it automatically created a logo for ContributorIQ as it set up the landing page. I hadn’t even asked for one, but it looked great, so I went with it!
Once I nail down a name and logo, I’ll return to ChatGPT yet again and use it like a rubber duck. Of course, I’m not doing any coding or debugging at this point; instead, I’m just using ChatGPT as a sounding board, asking it to expand upon my idea, poke holes in it, and so forth.
Next, I’ll create a GitHub repository and start adding issues (basically feature requests). I’ve used the GitHub kanban board in the past and have also been a heavy Trello user at various times. However, these days I keep it simple and create GitHub issues until I feel I have enough to constitute an MVP. Then I’ll use the GitHub MCP server in conjunction with Claude Code or Cursor to pull and implement these issues.
Before committing resources to development, how do you approach initial validation to ensure the market opportunity exists for a new SaaS product?
The answer to this question is simple. I don’t. If the problem is sufficiently annoying that I eventually can’t resist building something to solve it, then that’s enough for me. That said, once I have an MVP, I’ll start telling everybody I know about it and really try to lower the barrier associated with getting started.
For instance, if someone expresses interest in using SecurityBot, I’ll proactively volunteer to help them validate their site via DNS. If someone wants to give ContributorIQ a try, I’ll ask to meet with the person running due diligence to ensure they can successfully connect to their GitHub organization. It’s in these early stages of customer acquisition that you can determine what users truly want rather than merely trying to replicate what competitors are doing.
Execution, Tools, and Code
When deciding to build a new SaaS product, what’s the most critical strategic question you seek to answer before writing any code?
Personally, the question I ask myself is whether I seriously believe I will use the product every day. If the answer is an adamant yes, then I proceed. If it’s anything but a “heck yes,” then I’ve learned that it’s best to sit on the idea for a few more weeks before investing any additional time.
Which tools do you recommend, and why?
I regularly use a number of different tools for building software, including Cursor and Claude Code for AI-assisted coding and development, Laravel Forge for deployment, Cloudflare and SecurityBot for security, and Google Analytics and Search Console for analytics. Check out my comprehensive list at the end of this article for more details.
How do you accurately measure the success and adoption of your product? What key metrics (KPIs) do you prioritize tracking immediately after launch?
Something I’ve learned the hard way is that being in such a hurry to launch a product means that you neglect to add an appropriate level of monitoring. I’m not necessarily referring to monitoring in the sense of Sentry or Datadog; rather I’m referring to simply knowing when somebody starts a trial.
At a minimum, you should add a restricted admin dashboard to your SaaS which displays various KPIs such as who started a trial and when. You should also be able to quickly determine when trialers reach a key milestone. For instance, at SecurityBot, that key milestone is connecting their Slack, because once that happens, trialers will periodically receive useful notifications right in the very place where they spend a large part of their day.
On build versus buy: What’s your critical decision framework for choosing to use prebuilt frameworks and third-party platforms?
I think it’s a tremendous mistake to try to reinvent the wheel. Frameworks and libraries such as Ruby on Rails, Laravel, Django, and others are what’s known as “batteries included,” meaning they provide everything 99% of what developers require to build a tremendously useful, scalable, and maintainable software product. If your intention is to build a successful SaaS product, then you should focus exclusively on building a quality product and acquiring customers, period. Anything else is just playing with computers. And there’s nothing wrong with playing with computers! It’s my favorite thing to do in the world. But it’s not the same thing as building a software business.
Quality and Security
What unique security and quality assurance (QA) protocols does an intelligent SaaS product require that a standard, non-AI application doesn’t?
The two most important are prompt management and output monitoring. To minimize response drift (the LLM’s tendency for creative, inconsistent interpretation), you should rigorously test and tightly define the LLM prompt. This must be repeatedly tested against diverse datasets to ensure consistent and desired behavior.
Developers should look beyond general OpenAI APIs and consider specialized custom models (like the 2.2 million available on Hugging Face) that are better suited for specific tasks.
To ensure quality and prevent harm, you’ll also need to proactively monitor and review the LLM’s output (particularly when it’s low-confidence or potentially sensitive) and continuously refine and tune the prompt. Keeping a human in the loop (HITL) is essential: At Nomorobo, for instance, we manually reviewed low-confidence robocall categorizations to improve the model. At Adalo, we’ve reviewed thousands of app-building prompt responses to ensure desired outcomes.
Critically, businesses must transparently communicate to users exactly how their data and intellectual property are being used, particularly before passing it to a third-party LLM service.
It’s also important to differentiate when AI is truly necessary. Sometimes, AI can be used most effectively to enhance non-AI tools—for instance, using an LLM to generate complex, difficult-to-write scripts or reviewing schemas for database optimization—rather than trying to solve the core problem with a large, general model.
Marketing, Launch, and Business Success
What are your top two strategies for launching a product?
For early-stage growth, founders should focus intently on two core strategies: prioritizing SEO and proactively promoting the product.
I recommend prioritizing SEO early and aggressively. Currently, the majority of organic traffic still comes from traditional search results, not AI-generated answers (GEO). We are however certainly seeing GEO being attributed to a larger share of visitors. So while you should focus on Google organic traffic, I also suggest spending time tuning your marketing pages for AI crawlers.
Implement a feature-to-landing page workflow: For SecurityBot, nearly all traffic was driven by creating a dedicated SEO-friendly landing page for every new feature. AI tools like Cursor can automate the creation of these pages, including generating necessary assets like screenshots and promotional tweets. Landing pages for features like Broken Link Checker and PageSpeed Insights were 100% created by Cursor and Sonnet 4.5.
Many technical founders hesitate to promote their work, but visibility is crucial. Overcome founder shyness: Be vocal about your product and get it out there. Share your product immediately with friends, colleagues, and former customers to start gaining early traction and feedback.
Mastering these two strategies is more than enough to keep your team busy and effectively drive initial growth.
On scaling: What’s the single biggest operational hurdle when trying to scale your business from a handful of users to a large, paying user base?
I’ve had the opportunity to see business scaling hurdles firsthand, not only at Xenon but also during the M&A process, as well as within my own projects. The biggest operational hurdle, by far, is maintaining focus on customer acquisition. It is so tempting to build “just one more feature” instead of creating another video or writing a blog post.
Conversely, for those companies that do reach a measure of product-market fit, my observation is they tend to focus far too much on customer acquisition at the cost of customer retention. There’s a concept in subscription-based businesses known as “max MRR,” which identifies the point at which your business will simply stop growing once revenue lost due to customer churn reaches an absolute dollar point that erases any revenue gains made through customer acquisition. In short, at a certain point, you need to focus on both, and that’s difficult to do.
We’ll end with monetization. What’s the most successful and reliable monetization strategy you’ve seen for a new AI-powered SaaS feature? Is it usage-based, feature-gated, or a premium tier?
We’re certainly seeing usage-based monetization models take off these days, and I think for certain types of businesses, that makes a lot of sense. However, my advice to those trying to build a new SaaS business is to keep your subscription model as simple and understandable as possible in order to maximize customer acquisition opportunities.
Thanks, Jason.
For more from Jason Gilmore on developing successful SaaS products, join us on February 10 for our AI Superstream: Building SaaS Businesses with AI. Jason and a lineup of AI specialists from Dynatrace, Sendspark, DBGorilla, Changebot, and more will examine every phase of building with AI, from initial ideation and hands-on coding to launch, security, and marketing—and share case studies and hard-won insights from production. Register here; it’s free and open to all.
Picture a team arguing over whether to keep a global Redux store or roll out a context-only solution for a new React component. Minutes later, someone pushes a change that breaks the whole test suite.
A week later, another debate erupts about whether the REST API should be versioned or use a graph-based approach. And there’s always that one Git rebase that turns a quiet sprint into a full-blown firefight.
The line between brilliant innovation and productivity meltdown is thinner than you think – and ego is often the culprit lurking behind every heated Slack thread and passive-aggressive code comment.
What is egoless development?
Egoless development is not about surrendering conviction or becoming passive. It’s about letting the problem drive the solution, not the other way around. Gerald Weinberg, in his seminal work The Psychology of Computer Programming, wrote: “The most powerful learning occurs when someone produces a better solution than you had imagined.” If your ego can’t digest a “better” or “different” answer, you have no business leading a software team.
In practice, egoless engineering means:
Staying open to new ideas – even if they come from a junior teammate or an external library.
Focusing on the product’s value – not on proving your own architectural choices.
Accepting feedback without defensiveness – because every line of code is a hypothesis, not a manifesto.
Separating self-worth from code quality – your value isn’t measured by how rarely your code needs revision.
How ego shows up and undermines everything
Defensive responses to feedback
“That was how we did it before.”
Stifles incremental improvement and discourages team members from speaking up
Not-Invented-Here (NIH) syndrome
“We can’t use that library; it’s not ours.”
Drives tech debt, missed bugs, and stagnation while reinventing solved problems
Micro-management
“I will rewrite this myself.”
Silences creativity, hurts velocity, and signals distrust
Selective listening
“We only care about the UI.”
Neglects backend or infrastructure needs, creating systemic weaknesses
Knowledge hoarding
“I’m the only one who understands this module.”
Creates single points of failure and prevents team growth
Status-driven architecture
“Let’s use [trendy tech] because it looks good on my resume.”
Prioritizes personal branding over product needs
Ego erodes trust, inflates the perception of individual contribution, and turns collaboration into a zero-sum game. The consequences ripple outward: missed deadlines, higher bug counts, knowledge silos, and ultimately, a loss of team morale that drives your best people toward the exit.
The psychology behind code ownership
When we write code, our brains treat it as an extension of ourselves. Neuroscience research shows that criticism of our work activates the same neural pathways as physical threats. This is why a simple “This could be refactored” comment can feel like a personal attack.
Understanding this psychological reality helps us build better defenses:
Recognize the feeling – When defensiveness arises, pause and acknowledge it
Reframe criticism as collaboration – Someone improving your code is helping you, not attacking you
Build emotional distance – Use phrases like “the code” instead of “my code”
Practice receiving feedback – Like any skill, gracefully accepting criticism improves with practice
In 2015, during the “Brain Damage” incident, he dismissed a developer’s security proposal as “mindless security theater” and called it “brain damaged.” The developer stopped contributing, and the security concern became a real exploit two years later.
The fallout? Talented contributors left, community diversity dropped, and valid concerns were ignored based on who raised them.
After years of this, Torvalds took a break and issued a public apology in 2018, acknowledging that his ego had harmed the project and committing to a Code of Conduct.
Even brilliant technical leaders can cause real damage when ego outweighs empathy – but egoless engineering is a conscious choice.
Now let’s see egoless communication in action
This is my own example. It was 2:37 PM when my code hit production. By 3:00 PM, our monitoring tool sent alerts all over and showed 50 errors. New users couldn’t sign up. Existing users couldn’t complete their profiles.
This is where most teams spiral. Blame gets assigned. Confidence gets crushed. Someone becomes the cautionary tale.
Not this team.
The team lead’s first message: “Okay, let’s work the problem. Ivan, walk us through what happened – no judgment, just facts. Everyone else, what do we need to stabilize right now?”
My response: “I skipped the integration test because I thought it was just an isolated signup flow change. Clearly, I was wrong. I can roll back immediately, then we need to figure out why our CI didn’t catch this.”
Ten minutes later, production was stable. The retrospective didn’t focus on my mistake – it focused on the process gap. Why weren’t integration tests enforced for all changes? How could CI catch this automatically?
System got fixed and the whole team started advocating for comprehensive testing.
Lead with purpose, not ego
The antidote to ego-driven culture is a purpose-driven mindset. Put the team first: “Ship better products. Learn together. Celebrate collective wins.”
Adopt core values such as:
Open collaboration – Everyone’s input matters, regardless of tenure or title.
Continuous improvement – No single person owns the ship; we all keep it afloat.
Shared ownership – Success is a team metric, not a résumé headline.
Blameless culture – Focus on systems and processes, not individual fault.
Intellectual humility – “I don’t know” is a strength, not a weakness.
These values create a safety net that lets people experiment, fail fast, and iterate without fear of ego-related retribution.
How to cultivate egoless teams?
1. Morning coffee feedback sessions
Schedule a quick, informal chat with each teammate once a month.
Purpose: Surface concerns early, show genuine interest, reinforce the “we” narrative.
Pro tip: Keep it casual – grab actual coffee, go for a walk, or just sit outside the usual meeting room environment.
2. Code review as conversation
Treat every PR as a dialogue, not a verdict.
Instead of: “Why did you do that?” Try: “I’m curious about your approach to X – what tradeoffs did you consider?”
Key practices:
Assume good intent always
Ask questions before making statements
Provide context for your suggestions
Praise the good before noting improvements
3. Process-focused retrospectives
Avoid blame, focus on improving the workflow.
Outcome: The team learns to iterate on their own practices, identifying systemic issues rather than scapegoating individuals.
Framework to try: Use “What went well? What could be better? What will we try next?” instead of “Who caused the production incident?”
4. Celebrate team wins
Highlight milestones that benefited the whole product, not individual heroics.
Effect: Reinforces that value comes from collaboration. Consider a “Team Win Thursday” where you spotlight collaborative achievements in your all-hands.
5. Rotate responsibilities
Give everyone a chance to lead a sprint, own a component, or make architectural decisions.
Result: Empowers diverse viewpoints and reduces power-centered thinking. It also prevents knowledge silos and builds empathy for different roles.
6. Create a “learning debt” board
Just like technical debt, track what the team needs to learn.
How it works: Anyone can add skills or knowledge gaps. The team prioritizes learning together through lunch-and-learns, workshops, or dedicated study time. This normalizes not knowing everything.
Purpose-driven teams really excel
The data backs up the philosophy:
Faster problem solving – Collective knowledge surfaces solutions faster.
Higher-quality products – Diverse eyes catch more bugs; studies show pair programming can reduce bugs by 15-50%.
Happier teams – People feel valued beyond ego metrics.
Lower turnover – People stay when they feel part of something bigger; psychological safety is the #1 predictor of team success (Google’s Project Aristotle).
Innovation acceleration – When failure isn’t punished, experimentation flourishes.
In our own team, we’ve seen the difference. The “Misfit Days” workshops we introduced – short, daily stand-ups where anyone can bring a friction point- have slashed bug-backlog time by 35% and doubled the rate of new feature delivery. More importantly, our employee satisfaction scores jumped 28 points in six months.
Warning signs your team has an ego problem
Watch for these red flags:
Pull requests sit for days because no one wants to critique the senior dev.
“I told you so” moments are celebrated instead of collective problem-solving.
Knowledge hoarding where individuals protect “their” domains.
Defensive Slack threads that spiral into 47-message arguments over syntax.
Silent meetings where juniors don’t speak up for fear of looking stupid.
Resume-driven development where tech choices prioritize personal branding.
Hero culture where all-nighters and firefighting are glorified over prevention.
If you recognize three or more of these in your team, it’s time to intervene.
What should I do?
Ego is a silent saboteur that thrives in the quiet corners of code reviews and pull-request comments. It whispers that your solution is the only solution, that criticism is an attack, that admitting uncertainty is weakness. But the best engineering teams know differently.
By embracing egoless engineering – focusing on shared purpose, valuing every voice, and making collaboration the default – we turn potential productivity meltdowns into engines of innovation. The code improves, the products ship faster, and most importantly, people actually enjoy coming to work.
Remember: The best code you’ll ever write is the code you wrote with others. The best solution you’ll ever implement is the one that made someone else’s idea better. And the best career move you’ll ever make is building a reputation as someone who makes everyone around them better.
Starting tomorrow:
Implement a monthly open-feedback routine – Put it on the calendar now.
Audit your code review comments – Are you asking questions or issuing verdicts?
Celebrate a team win – Find one this week and make noise about it.
Try one new strategy – Pick from the list above and experiment for a sprint.
Every idea is respected. Constructive feedback is not just welcome; it’s required. Success is measured by shared achievements, not individual credit.
Log in
