Job Description
Description
You’ve had experience taking a software product from zero to launch, but you know that deep, thoughtful product work doesn’t end. You’re the kind of person who figures things out without a map, who goes deep on understanding the user, the problem, and the domain until a clear path emerges. You don’t want to manage a backlog or fill in a spec. You want ownership of a goal that matters and the space to pursue it with speed, insight, and focus.
At Trilogy, we’re flipping the model. You’re not here to “own the roadmap”. You’re here to make one thing true: a real-world, measurable business outcome. You get one clear goal—something that should happen when users interact with the product—and your job is to make it happen. You’ll need to build deep domain insights using AI as your peer and feedback from users, codify them so that both your teammates and AI can act on it, and steer the product through fast, data-backed iterations until you hit the outcome.
You’ll be joining a team that doesn’t celebrate busywork or beautiful process diagrams. You’ll be there to drive impact and make decisions rooted in user data, fast feedback loops, and sharp insight. If you’re sick of playing the PM game and want to actually change the game, please apply. We’re building what product management should have been all along.
What you will be doing
- Build BrainLifts: A structured, evolving body of expert insights that sharpens AI tools, guides decisions, and proves you understand the domain.
- Make Product Iterations: Small, data-driven product enhancements shipped weekly to steer the product toward a measurable outcome.
- Building Domain Expertise: Acquire deep, structured understanding of a specific domain so that the team can make higher-quality decisions, create more tailored outputs, and communicate with authority.
What you will NOT be doing
- Spending a whole month developing a new feature; we aim to ship new features on a weekly basis
- Writing lengthy and exhaustive PRDs, managing backlogs, or defining every screen or edge case
- Building technical solutions or software architecture
Candidate requirements
- 4+ years in a product leadership role in a product company, where you personally shaped an entire software product’s vision, defined the roadmap, and improved it based on usage metrics or customer feedback (i.e., not just a feature or a module in a bigger product, and not internal development or outsourcing work or custom development done for a single customer)
- Some experience in product management of software used by large enterprises, so you can understand the particularities of how large enterprises choose, buy, and adopt software, compared to consumers or even SMBs.
- Technical background that enables discussing data models and system design trade-offs. Backed up by either formal education in Computer Science, or practical hands-on experience as a developer/coder of at least 1 year.
- Enthusiasm for using AI in your daily work (e.g., research, analysis, synthesis, or strategy).
First Round - Bogdan
Hello Ashwin,
While in many companies a broad discussion about work experience is typical, I like to do something different for my interviews.
Our view on product management has evolved over the years to 3 fundamental requirements for someone to be successful in this role:
- Relentless pursuit of outcomes through focus on the user, on data, on evidence, and rapid feedback cycles - then you’re not living in your world, you’re living in the real world.
- Become a deep expert in the domain, the user, and the problem, and have real insights, and take positions where experts disagree, so you can define good A/B tests, good features, and a product.
- True openness to using AI to build domain expertise, explore new ideas, interpret data, prototype features, etc., but not just as a tool but as a peer; yet, not a replacement for discernment.
Given this background, I’d like to discuss a product role where you were the captain of the ship, and you had true ownership of how to reach the end goal:
- What was the customer problem you were solving?
- What was the success metric/outcome from the user’s perspective?
- How did the product solve this?
- How was it differentiated from competitors?
After we get through these basic questions, I’d like you to describe 1-2 decisions that you made that were hard/challenging/important - something that, for someone without domain expertise, the obvious answer would be wrong, and you learned it from trying things with live users, looking at data, and user feedback, and iterating.
Regards, Bogdan Tenea SVP of Product Management
Second round with Serban
Interview structure
Interview flow (~45 min)
0-5 min Warm-up, quick intros 5-20 min Product: the most difficult product (i.e., not orga, engineering, comms, etc) decision that you took. What outcome did it drive, what options did you explore, how did you know whether or not you were successful at the end, etc? 25-40 min Role-specific questions • Product: more scenarios around decision making, recovering from failures, and stakeholder management. 40-45 min Your Q&A, wrap-up & next steps
Candidates
Strategic Pivot of Code Studio during your time as Head of Product at Coding Ninjas.
This story is highly effective because it focuses on a core product strategy decision that was high-stakes and validated by data.Recommended Story: Pivoting the Code Studio Experience at Coding Ninjas
| Criteria | Story Details |
|---|---|
| The Difficult Product Decision | To strategically pivot the free Code Studio platform’s core experience from an initial focus on interview preparation to a primary focus on core coding problems. The decision was difficult because you had to “navigate skepticism toward free offerings” and justify prioritizing core content over perceived immediate value like interview prep. |
| Options Explored | The two main options were maintaining the focus on interview experiences (which wasn’t driving retention) or shifting to core coding problems. You explicitly explored this via an A/B test that “swapped interview experiences for code problems on the homepage.” |
| Outcome | The A/B test showed increased code problem attempts and significantly higher cohort retention. This strategic shift led to the development of a gamification layer (Octalysis model), which drove organic growth. The product became the single most important asset for the company. |
| How Success Was Measured | Success was quantified with clear, measurable product metrics and a major business outcome:
|
The “Captain Coder” Pivot
| Scenario | Details from the Document |
|---|---|
| The Decision | Leading the product strategy for “Captain Coder,” a new venture into live classes for kids, based on the assumption of market opportunity during COVID-19. |
| The Failure/Recovery | The initial business model proved unsustainable due to high operational costs relative to revenue. The recovery involved swiftly acknowledging the failure and immediately championing the development of the free Code Studio platform, using the learning from the paid-model failure to drive a strategic, free-content acquisition model. |
| Stakeholder Management | Required convincing the team/founders of the new, counter-intuitive strategy: that offering free content (Code Studio) would build market trust, provide a competitive advantage, and ultimately lead to monetization/acquisition. |
- Recovering from Failures: Fixing the Code Editor UX
| Scenario | Details from the Document |
|---|---|
| The Decision | The “leap of faith” decision to prioritize and invest in a complete overhaul of the code editor user experience (UX) by switching to a new editor and redesigning features like test case placement, without a clear, direct guarantee of retention improvement beforehand. |
| The Failure/Recovery | The existing editor was initially “haphazard and not user-friendly,” which was a failure of the initial product design. Recovery was measured by a data-backed UX survey (1,000 responses) which established the initial average rating of 3.4 out of 5 as a “North Star metric.” You successfully drove investment to increase the rating to 4.2 in the following quarter, directly addressing the core user dissatisfaction. |
| Stakeholder Management | Involved convincing the team to invest in an “abstract rating” improvement, demonstrating the use of data (the survey and cohort analysis) to drive product priorities, even over features with more immediate, quantifiable retention links. |
- Stakeholder Management & Culture: Building High-Performing Teams
| Scenario | Details from the Document |
|---|---|
| The Decision | The personal decision to mentor two Associate Product Managers (APMs), including a data analyst transitioning into the role, after other PMs declined to hire them. Also, the decision to manage product, design, and data teams simultaneously. |
| Stakeholder Management | Successfully nurtured and developed the APMs to achieve “exceptional performance” and impressed peers and co-founders. Managed the complex, cross-functional alignment of the product, design, and data teams, which required “significant context switching” and ensuring all teams worked synchronously. You also had a direct working relationship with two co-founders and were considered essential for sign-off. |
| Recovering from Failure | Actively addressed a personal failure to receive enough feedback from your own boss by codifying the PM skillset (based on the Ravi Mehta model) and institutionalizing clear quarterly goal-setting and progress summaries for your own team. This is a story of using a past organizational flaw to build a better culture. |
Questions
- Which sister companies are we talking about
- 3 pillars (dart example)
-
Become a domain expert
-
Clear set of requirements ⇒ Flows
-
Analyse data and create experiments
-
Stakeholder management
-
roadmap articulation Transparency
-
Contractor
- Leave
- Overtime?
- Time tracker. Hired / Fired
Final Round - Samy
Profile of Samy
⭐ SAMY ABOEL-NIL — EXECUTIVE PERSONA FOR INTERVIEW PREP
(Psychological + professional + decision-style + evaluation-style)
🔥 1. Core Identity: The “Expert Generalist Builder”
Samy is someone who deeply believes that being an expert in the problem is the single greatest advantage in product. His self-identity:
- Expert before anything else
- High standards
- Hyper-logical
- Clarity-driven
- Outcome-oriented
- AI-maximalist
- Loves deep problem insights
- Obsessed with data structures, algorithms, and architecture as product-level differentiators He is not a “process PM” interviewer — he is a first-principles, systems-thinking builder.
🔥 2. His Core Values (This is the part you must align with)
A. Depth of Thought → “Be an Expert”
He believes PMs must:
- Master the domain
- Learn the user deeply
- Reverse-engineer real constraints
- Build a mental model sharper than anyone else Shallow answers, vague reasoning, and hand-wavy product logic will fail. He respects:
- Codified insights
- Structural explanations
- Tight decision frameworks
B. Radical Clarity and Brevity
He’s extremely allergic to:
- Long context dumps
- Meandering stories
- Rambly product narratives
He wants:
- The decision
- The trade-offs
- The data
- The hard part
- The measurable outcome
Everything else is noise.
C. High Standards + Controlled Scope
His philosophy is:
- Hold bar for quality extremely high
- Keep scope extremely tight
- Iterate rapidly
- Don’t tolerate excuses
- Don’t get lost in “PM busywork”
- Don’t overbuild He is allergic to:
- Over-polished frameworks
- Process for the sake of process
- PMs who want to “run the roadmap”
- Anyone who cannot prioritize ruthlessly
D. AI-(First)-Everything
His worldview now:
- Use AI relentlessly
- Use AI to augment thinking
- Use AI to accelerate iterations
- Use AI to validate assumptions
- AI is a teammate, not a tool He will expect that you:
- Already work deeply with AI
- Use it daily
- Have real examples of AI accelerating product insights
- Show that you think AI-native
🔥 3. The Types of Answers He Loves
1. Sharp, compressed stories
Example structure he responds well to:
- “The insight was…”
- “The hard part was…”
- “The decision came down to X vs Y vs Z…”
- “We shipped this experiment weekly…”
- “Here was the measurable outcome…”
No fluff.
No backstory.
Just surgical clarity.
2. Counter-intuitive insights
He loves when you say:
- “Everyone believed X, but the data showed Y.”
- “The real behavior contradicted the narrative.”
- “The hard part wasn’t execution — it was realizing the actual problem was Z.” This shows you think in first principles.
3. Product-as-a-System (not as screens)
He admires PMs who can talk like:
- “The retention loop was broken because the trigger → action → reward flow was too high-friction.”
- “We redesigned the underlying structure of the experience, not the UI.”
- “The data model didn’t support the natural user behavior.” He believes great PMs think in systems, loops, constraints, and models, not features.
4. Unambiguous “hard parts”
He’ll ask repeatedly:
“What was the hard part?”
He’s not fishing for:
- drama
- politics
- delays He is fishing for:
- Ambiguity
- Hard trade-off
- Missing data
- Stress test of your reasoning
- Structural tension
- Something only an expert PM would understand
Example (for you):
“In Code360, the hard part wasn’t the coding. It was convincing the org that interview-prep wasn’t the behavioral anchor — practice was.”
🔥 4. What He Will Test You For
A. Can you isolate the one key insight?
He will interrupt often.
He wants to know:
- What EXACTLY changed your direction?
- What EXACTLY was the decisive insight?
- How EXACTLY did you validate it?
If you wander → you die.
If you compress → he’ll lean in.
B. Can you articulate a real decision tree?
He will push for:
- What were the options?
- Why did you reject the others?
- How did you evaluate trade-offs?
- What was your model? He wants to see a trained decision athlete, not a storyteller.
C. Can you codify your insights?
He will judge your ability to turn intuition into:
- A rule
- A framework
- A repeatable pattern
- A model he can give to an AI agent This is directly tied to Trilogy’s “BrainLift”.
D. Can you speak with CTO-level clarity about technical constraints?
He doesn’t expect you to code. But he expects you to:
- discuss data models
- understand the impact of architecture
- explain technical trade-offs in structured English
- show that “product decisions” often come from “technical truths”
E. Are you AI-native?
He’s looking for:
- AI used for analysis
- AI used for iteration
- AI used for research
- AI used for decision validation Your Umbra + consulting experience fits perfectly here.
🔥 5. His likely biases when evaluating you
POSITIVELY BIASED BY:
- Your deep EdTech experience
- Your genuine, domain-heavy learning insights
- Your Code360 pivot story (he already likes it)
- Your TA system story (two-sided market + matching system — he LOVES this)
- Your AI-native projects (Umbra)
- Your data-driven approach
- Your fast-iteration product style
- Your “expert in domain” posture
NEGATIVELY BIASED BY:
-
Over-long answers
-
Trying to narrate context
-
Sounding too PM-polished (PRD/backlog talk)
-
Feature/UX-level focus instead of system-level
-
Lack of clear decision-tree
-
No “this was the hard part” articulation
-
No codified insight
-
Over-indexing on “team / leadership” instead of “product thinking”
🔥 6. The ONE THING he cares most about
If you master this, you will pass:
“Can this person take a real, ambiguous, high-stakes problem, go deep, find the actual insight, and drive it to a measurable win?”
That’s it.
Everything else is secondary.
🔥 7. How to speak to Samy (Your interview communication style)
-
Start with the decision
-
Then the options
-
Then the hard part
-
Then the insight
-
Then the data
-
Then the outcome
Your answers must feel like:
-
confidently compressed,
-
logically structured,
-
technically aware,
-
expert-level.
🔥 8. Your persona match (You’re actually a strong fit)
Samy will like:
-
Your obsession with data
-
Your strong behavioral insight modeling
-
Your pivot courage
-
Your retention-first thinking
-
Your experience with TA marketplaces
-
Your experience with algorithmic scoring (ELO)
-
Your PKM + EdTech + adaptive learning background
-
Your AI-heavy experimentation
You already match his worldview.
Your job is not to impress him with breadth.
Your job is to show depth + clarity + one killer decision story.