Table of Contents
At LearnWorlds, we’ve built a suite of authoring tools – Website Builder, Assessment Builder, Form Builder, Mobile App Builder – that consistently outperform competitors in one crucial dimension: customizability and flexibility for content creators.
Despite operating with a small team, minimal layers of process, and a playbook that many would call unorthodox, we’ve managed to deliver tools that give creators more power, more control, and more creative freedom than platforms built by companies ten times our size.
And that’s not an accident.
This article is for product leaders – CPOs, Heads of Product, PMs – who are building authoring tools, or any software that serves as a canvas for creation. You won’t find a framework or maturity model here. What you’ll find is a map of how to think, how to collaborate, and how to move fast in a space where ambiguity is the rule – and flexibility is the product.
From first-order problems to possibility design
Most product managers are trained to think in terms of first-order problems: you discover a pain point, define a clear problem, validate it, then design and ship a targeted solution. This model works well for transactional software – dashboards, workflows, settings panels – where the path from user need to solution is short and direct.
But authoring tools live in a fundamentally different space. They don’t just solve problems – they create environments in which users can solve their own problems. These are what we call second-order problems: you’re not offering a fixed output, but rather a set of capabilities, constraints, and primitives that allow someone else – the creator – to achieve a goal that may be unknown to you at design time.
That subtle shift changes everything.
When you build an authoring tool, your job isn’t to just resolve friction – it’s to enable expression. You’re no longer building utilities. You’re building possibility. You are, in essence, designing a creative medium. And the needs of a creative medium aren’t always linear, nor are they neatly specifiable.
Your users may not be able to articulate exactly what they want – not because they lack insight, but because they haven’t yet imagined what’s possible. And it’s your tool that will help them imagine it.
This is why traditional discovery and validation methods fall short. The better question for the authoring PM isn’t just “What problem am I solving?” but rather:
“What kind of creative decisions will this enable?”
“What kind of user complexity will this unlock – or reduce?”
That’s the heart of second-order product thinking.
What traditional PM culture gets wrong
The modern product management playbook – shaped by consumer tech, enterprise SaaS, and metrics-driven growth teams – is built on principles like validated learning, customer interviews, tight problem-solution alignment, and incremental delivery tied to measurable impact.
And while that approach makes sense in fixed, linear systems, it becomes brittle in the world of authoring tools, where:
Here’s what traditional PM culture fails to grasp:
1. You can’t spot opportunities if you can’t see the code
In authoring tools, technical opportunity is often the best form of leverage.
One new component, one refactored architecture, one well-designed pattern can unlock a dozen use cases for free – with zero additional design, support, or product overhead.
But most PMs, especially non-technical ones, lack the intuition to recognize when something is a “cheap win” versus a “technical iceberg.” To them, two feature requests – “Add a checkbox to do X” and “Add a checkbox to do Y” – look identical. But under the hood, one might take an hour to implement, and the other might require a full rewrite of the state model and break the rendering engine.
Without that understanding, prioritization becomes theater.
You end up making trade-offs based on flawed information, falsely assuming symmetry between efforts that are wildly different in cost and impact.
2. Product designers and Developers are not “stakeholders” – They’re peers
In the context of authoring tools, no one has the full picture. Not the PM. Not the designer. Not the engineer. Each sees a different slice of the opportunity space.
Which means the old-school waterfall dynamic – where the PM defines the need, the designer mocks it up, and the engineer builds it – collapses completely.
What you need instead is a flat, collaborative model, where:
Everyone co-shapes the opportunity space. Everyone contributes to how the solution emerges. Everyone is responsible for deciding what’s “worth it.”
This is not a utopian ideal – it’s a pragmatic necessity when building flexible, scalable creative platforms.
3. Rigid process kills cheap brilliance
That kind of initiative only surfaces in teams where technical voices are heard, where PMs don’t treat devs like order-takers, and where opportunities are evaluated in real time, not just in grooming meetings.
Traditional product culture often rejects these “off-plan” contributions in the name of focus and roadmap discipline.
But in creative software – especially authoring tools – focus isn’t about filtering out noise. It’s about building the mental agility to spot value where it emerges, and building the team’s trust to act on it fast.
4. The best authoring tools are built in context, not in theory
Most teams treat implementation as execution. But in authoring platforms, implementation is exploration.
The moment a team starts working on a toolbar, an editor module, a dynamic container – that’s the moment when the real understanding emerges. And it’s often the best time to make decisions, add enhancements, question assumptions, and reframe user flows.
If you defer those decisions to the next cycle or wait until the feedback is in, you’re operating with a dead context – and you’ll ship something slower, less integrated, and probably less ambitious.
Great authoring teams optimize for contextual acceleration – doing more, better, faster, precisely when they’re deep in the technical and creative details.
Bottom line: authoring tools demand product fluidity
If you’re building an authoring product with rigid roles, rigid process, and rigid validation, you will build something safe – and forgettable.
If you’re willing to embrace technical collaboration, decentralized creativity, and real-time opportunity surfacing, you might just build something magical.
In this space, certainty is overrated. Awareness is power. And flexibility wins.
And What Is Product Discovery, Really?
A phase – or just a few AI prompts away from product breakthrough?
In traditional product organizations, discovery is treated as a structured, gated phase. Interviews. Surveys. Competitive analysis decks. A research sprint. A backlog of validated “needs” that someone eventually prioritizes.
But if you’re building an authoring tool, this model isn’t just slow – it’s strategically insufficient.
Why?
Because in authoring environments, as we discussed earlier, product value emerges not from ticking off validated needs, but from identifying and acting on opportunities – small design shifts, UX enhancements, feature extensions, composability improvements – all of which depend on:
This is where AI changes the game completely.
AI doesn’t just make discovery faster – it redefines who gets to discover, how often, and how deeply.
Let’s be specific:
Before AI, these tasks required designers with deep domain knowledge, researchers with weeks of bandwidth, or expensive external agencies.
Now? You’re a prompt away.
And here’s the key:
Let’s connect this with the previous point:
In the kind of flat, high-context, developer-designer-PM teams we described, where decisions are made inside the implementation window – the ability to enrich those decisions with fast, AI-powered insights transforms every sprint.
This is not just efficiency.
This is multiplication of product imagination – right when it matters most.
And the result?
From need to opportunity: The real craft of authoring product teams
Let’s bring it all together.
We’ve argued that in authoring tools, value is not driven solely by user pain points or validated backlogs. It’s driven by how intelligently and creatively your team responds to need – and how effectively it multiplies that response through technically elegant, lightweight, and context-aware enhancements.
And that leads us to the core principle of this entire article:
You start with the need.
You solve the need.
And then – you unlock more value through fast, smart, and technically opportunistic extensions.
This is not a nice-to-have.
This is the real craft of building great authoring tools.
The PM as opportunity curator
In this model, the product manager is not just an orchestrator of roadmaps or a validator of market signals. The PM becomes an opportunity curator – someone who listens deeply to the core needs of users, but then zooms out and asks:
In authoring tools, especially, you often open one component – a toolbar, a layout grid, a settings panel – and in doing so, you unlock a moment of leverage. You’re deep in the architecture. Your developers are “in context.” The design space is fresh in everyone’s minds.
This is the moment to act.
If you only implement the bare minimum requirement, close the ticket, and move on – you’ve missed the opportunity.
Instead, the high-leverage move is to treat the moment as fertile ground for value expansion:
From opportunity to differentiation
And here’s the most important part:
Authoring tools are differentiated not by how many features they have – but by how many thoughtful, empowering, well-connected details they contain.
These small but smart additions – made during context-rich implementation moments – are what give your product that feeling of depth, elegance, and fluency.
This is where great teams win.
They don’t just chase features.
They explore edges, make brave little bets, and ship things that others didn’t think to try – or thought were too marginal to matter.
But they do matter.
Because in a space where customization is the value, where flexibility is the brand, and where creators push your product to its limits, these small opportunities compound – into better outputs, happier users, and a tool that people trust to build their best work.
The real differentiator: Hunger for the better tool
This is where we part ways with traditional PM thinking once and for all.
If you operate from a defensive posture – only reacting to validated problems, only building what’s “safe,” only shipping what has a clear, measurable ROI – then you’ll always be one step behind.
But if you lead with curiosity, with creative hunger, and with a team that can move fast inside open spaces of possibility – then you will build something better.
Not louder. Not bigger. Better. That is the authoring tool that stands out. That is the team that plays the long game. And that is the kind of PM you should aim to be.
The fallacy of perfect measurement
One of the most common objections to this fast-moving, opportunity-driven approach is the classic product management question:
“But how do you measure it?”
And the honest answer is: often, you can’t – at least not directly.
When your authoring tool is a suite of 100+ modular tools, and you improve module #9 through #15 – refining toolbars, optimizing layouts, smoothing configuration logic – the impact won’t show up in your dashboard the next day. It won’t create a clean A/B uplift. It won’t drive an obvious spike in conversions.
But here’s what you will notice:
That’s impact.
And it comes not from waiting for statistical proof, but from embracing qualitative awareness, product intuition, and team-level signal.
The best authoring teams know this. They start from a need. They solve that need with clarity.
And then – they multiply the value through fast, technical, creative enhancements.
Back to Careers
Scroll to top