From Theatre & Commodities to Scaling BlogHer: Elisa Camahort Page’s Journey

Elisa Camahort Page has had three careers, and the thread running through all of them is showing people that new tools can expand what they are capable of. She co-founded BlogHer in 2005, bootstrapped it for two years before raising funding, and helped turn a single conference into the media company that arguably started the creator economy. Before that she spent seven years in commodities and seven in cable telecoms, having arrived in tech as a marketing admin who promised her interviewer she would be the best admin he had ever had for exactly one year. She now builds her own AI-powered tools and teaches other people to do the same. In this episode she talks to Rob Woodhead about starting over at any age, why mentorship works better as a squad than a single person, what happened to product management when Silicon Valley decided it belonged in engineering, and why most of the people who say they are vibe coding are doing something else entirely.

Key takeaways

• Changing direction is far less risky than it feels. Elisa's advice to anyone hesitating is that you are much more likely to discover you do not enjoy a job than to discover you cannot do it.
• Mentorship works better as a squad than a single person. One mentor for business judgement, another for technical depth, and a habit of finding the people who are delighted that somebody finally asked about their work.
• Product management was originally a translation role sitting between engineering and sales, owning the P and L. Elisa argues that moving it into engineering was gatekeeping presented as rigour, and that it pushed a lot of women out of the discipline.
• Most people who say they vibe coded something actually vibe product managed it. They wrote requirements and made product decisions, which is a different skill from writing code and a different set of risks.
• The way in is something low stakes and enjoyable. Elisa's first serious use of AI was a six-week curriculum to relearn tarot, followed by one to learn Spanish, neither of which could damage anything if it went wrong.
• AI reflects the framing you give it. Elisa has instructed Claude never to write for her, to ask questions instead, and to flag when something is framing rather than fact.
• When a company says efficiency, employees hear replacement. Hackathons where people fix their own small frictions get adoption that top-down mandates do not.
• Work out how you want humans in the organisation to learn and advance before deciding how AI should support them. Doing it the other way round is how companies make people redundant and then rehire them.
• The honest test of AI-assisted work is not detection. It is whether the person can explain how they got there and defend what they produced.

Episode chapters

• 01:40 Origin story: a first-generation American childhood
• 04:22 Why starting over is normal, not brave
• 07:17 Moving to New York to pursue theatre
• 11:37 Deciding at twenty five that theatre was not the life
• 14:31 An accidental seven years in commodities trading
• 18:32 Why Silicon Valley calls it the dot-com boom
• 19:22 Getting into tech as a marketing admin
• 24:19 The interview promise that worked
• 25:51 The only woman in the room
• 28:01 Build a squad, and look for the helpers
• 31:13 What product management used to be
• 34:40 How product management became gatekept
• 36:17 The genesis of BlogHer
• 44:33 Getting President Obama onto the keynote stage
• 51:05 Knowing straight away that it was working
• 53:45 Staying on through the acquisition
• 59:08 Writing the book, and what came next
• 1:01:19 Why freedom matters more than funding
• 1:03:09 Vibe coding versus vibe product managing
• 1:05:06 Learning Spanish, and starting with something fun
• 1:07:28 AI as a mirror
• 1:09:22 Hackathons instead of mandates
• 1:14:58 Where AI actually earns its keep
• 1:18:24 The Working Girl test for AI-assisted work
• 1:22:45 Never turn your back on the ocean
• 1:28:10 The walk-on song

Starting over is more common than the career advice suggests

Elisa's first model for this was her mother, who married the June she graduated, had three children by twenty seven, and then in the 1970s read The Feminine Mystique and decided she wanted to work. She started as a part-time research associate and became that company's first female vice president, and the first woman they were willing to send to Japan at a time when the prevailing belief was that you could not send a woman to do business there. She did not retire until she was seventy.

Two lessons stuck. You can always start at the beginning, and there will be consequences, in this case a marriage that did not survive it. And the cards being stacked against you is not the same as the opportunity being closed.

Elisa has now done it repeatedly. She left theatre at twenty five, fell into commodities trading because a family friend needed an assistant, moved into tech seven years later, and was over forty when she started BlogHer. Her framing for anyone hesitating is deliberately unromantic. It is far more likely that you will get into something and work out you do not like it than that you will get into it and find you cannot do it.

Rob suggests courage is the wrong word for this, and Elisa agrees. She would call it self-confidence that you will work it out, or a sense that things tend to find their way. The version she quotes came originally from Genevieve Bell's mother: if it will not result in death or dismemberment, it is probably worth a try.

Mentorship works better as a squad than as one person

Elisa has updated the standard advice about finding a mentor. Asking one person to carry that whole function is hard to request and hard to fulfil. Her alternative is to build a squad, with different people covering different things.

At the cable telecoms company where she started as an admin, the VP of marketing became her business mentor, largely by letting her sit in on meetings she had no business attending. Nobody else brought their admin to those rooms. She was not expected to contribute, she was absorbing how negotiation and collaboration actually work.

There is an uncomfortable detail in that story and Elisa tells it anyway. He later admitted part of the reason was that he thought the men behaved better with a woman present, which is not the same as giving that woman any power in the room. Her read on it is that she did not gain power, but she gained an enormous amount of knowledge, and she was content with that trade at the time.

The technical education came from somewhere else entirely. A newly minted PhD in charge of the first digital product line wanted help with writing, and decided she would write better if she understood the subject, so he whiteboarded the shift from analogue to digital telecoms for her. She repeated the approach at her next company with an RF engineer nobody ever visited, and then with a semiconductor specialist. Her point is that the stereotypes about those roles are unreliable. Plenty of people are delighted that somebody finally asked about their work, and helping you understand it makes their own job easier.

Product management used to be a translation job before it became a gatekept one

This is a piece of Silicon Valley history Elisa thinks is not well known. Before Google, product management lived inside marketing, not engineering. It sat in the space between engineering and sales, carrying customer requirements in one direction and benefits rather than features in the other, because engineers tend to describe the feature and assume the benefit is obvious.

Elisa was well suited to it precisely because she had recently had to learn all of it herself, from engineers and from salespeople, so she knew what it felt like to need something translated. Product managers in that era also owned the P and L for their products and had to defend every choice against it, which she describes as a good education.

She also makes an argument for hiring people with theatre backgrounds rather than only sports backgrounds. Theatre means creating something from nothing, repeatedly, with a group of very different personalities where there is a role for everyone from the stagehand to the conductor. It teaches adaptation, thinking on your feet, and covering for each other when somebody drops a line, which is a reasonable description of shipping software.

Then companies started emulating Google, product management moved into engineering, and an engineering background became the assumed qualification. Elisa's view, which she is clear is an opinion with some data behind it, is that this was gatekeeping and the preservation of an existing power structure rather than a genuine requirement. A lot of women who had been doing the job were reclassified as no longer qualified.

The same tension shows up in how we structure delivery teams on client projects. You can see how that plays out across our client work.

Most people who say they are vibe coding are vibe product managing

This is the line from the episode most worth sitting with. When people tell Elisa they vibe coded something, her response is that they vibe product managed it. They did not write the code. Some people do go into it, but most of the people she knows who describe themselves as vibe coding are making product decisions and writing requirements, which is a different activity with a different failure mode.

For her this is a return to what she already loved doing, and she is having a good time with it. The distinction matters commercially too. Someone who has vibe product managed their way to a working prototype has genuinely proved something about what they want, which is not nothing. What they have not established is whether the thing underneath it is safe to build on.

That is the question our Vibe Code Audit answers. If a prototype has proved the idea, the useful next step is knowing what the code beneath it will cost in security, scalability and maintenance before anyone commits to scaling it.

AI reflects the framing you give it, so the framing is the work

Elisa's route in was deliberately trivial. She took the advice of writer Alexandra Samuel, who starts with something fun and low stakes when trying new technology, on the grounds that there is no sense learning a tool on something where a mistake causes real damage. Elisa asked for a six-week curriculum to relearn reading tarot cards. Could she have built that herself, having designed programmes for large conferences? Yes. It was more fun not to.

Then she asked for a Spanish curriculum, with a lot of context attached: her father's first language was Spanish, she grew up hearing it at family gatherings but never learned it, she has read Spanish signage in New York and California for decades, and she specifically wanted Californian Spanish rather than a textbook version. Four months on she can read most of it comfortably.

The insight came from an exchange where she was feeling low about a piece of work and the model was harsh with her. Her first reaction was to ask where the sycophancy had gone. Her second was to push back, which prompted an apology, and from that she drew the general rule: it can only tell you what you feed it. You provide the frame and the context, and you can change both.

So she has set rules. Claude never writes for her. It asks questions instead, because questions are generative. It captures what she and the model call sparks, interesting fragments from conversations and meeting notes that she might write about later. She has also told it never to repeat framing as fact. When it briefs her on politics and uses a phrase like progressive versus establishment, it has to say who framed it that way and what their background is, because that is a framing rather than a tangible fact.

Rob has taken a similar approach, requiring Claude to challenge him on something before agreeing with him. Elisa is honest that she has left one piece of flattery in place. Working alone in a home office means no head-nodding energy in the room, and when the model tells her a question is sharp, in a British male voice she chose for her morning briefings, she takes the small hit of encouragement. She can see exactly why she likes it, which is arguably the point.

When leadership says efficiency, employees hear replacement

Elisa's framing for her own work is self-actualisation rather than self-replacement, enrichment rather than efficiency. That is not just phrasing. When people are told the goal is efficiency, what they hear is that they are being asked to train their own replacement, which has happened to enough people that the suspicion is earned.

Her alternative is to let people fix their own small frictions and share what they built. She points to hackathons as the format. The example she gives from her own setup is a clipboard utility living in her Mac menu bar that keeps the last ten things she copied, built because writing a newsletter means constantly juggling a link, an image, some alt text and a caption, and the thing she needs is usually two copies ago. Friction costs time, but it also costs attention, which is the more expensive of the two.

She has since gone through her own workflows looking for the tasks she still does manually every week, including prompts she was retyping on a schedule, and automated them so the output is waiting for her instead.

The sequencing advice for leaders is the sharpest part of the episode. If an organisation cannot articulate how it wants humans to learn, grow and advance, it is too early for it to be asking how AI should augment the work. Decide what humans still own and how they develop, then ask how AI supports that. Skip that step and low morale is the predictable outcome, along with the pattern of cutting people, realising you needed them, and hiring them back, which is what happened with offshoring after the dot-com bust.

The test is whether someone can connect the dots

Elisa is unpersuaded by the detection arms race. Using an AI tool to detect AI makes little sense if your objection is environmental, and even less if your objection is hallucination. Her stronger concern is that detection gets weaponised, and that the people it gets used against will be the ones who already have to work hardest to be taken seriously.

Her replacement test comes from the film Working Girl. The junior character wins because she can show exactly how she arrived at the idea: this clipping, then this one, then the connection between them. The executive who claimed the idea cannot explain a single step of it, and that is what gives her away.

Applied to AI-assisted work, the questions are whether you find the writing good, whether the person can back it up, whether they could answer a question about it, and whether they can explain how they got there. Elisa can often spot the cadence of a model in someone's writing, and her view is that it does not much matter if the answer to those questions is yes.

She applies the same scepticism to her own use of it. She has a fact-checking skill, adapted from a journalism professor, that requires every source to be surfaced. Her comparison is with a junior colleague: you do not accept their first draft without checking it, and you should not accept this one either.

Nobody should turn their back on the ocean

Elisa's closing metaphor comes from a rescue near Santa Cruz. Lifeguards are trained never to turn their backs on the ocean, and in the footage the lifeguard keeps facing the water even as the waves break over him.

She applies it in two directions. We should not turn our backs on the ways this technology gets weaponised or on the need for corporate and governmental policy to do a better job than it did with social media. And individuals should not turn their backs on it either, because deciding not to look at it does not stop it arriving.

Her practical version of this is blunt. If your position is that nothing can replace you, you had better know what it can actually do, and the only way to know that is to use it and watch it fail. It does annoying, stupid things constantly, and you will not find out where unless you try it somewhere the stakes are low.

Her own example is a meal planning app to reduce food waste, an idea she had fifteen years ago and was told would need three separate engineers: a database specialist, an interface designer and a machine learning person for the preference modelling. She built it herself, uses it for her weekly vegan meal planning, and recently spent under an hour making a version she can share with friends. It was not effortless. She has it.

About the guest

Elisa Camahort Page is co-founder and former COO of BlogHer, the women's media company she started with Lisa Stone and Jory Des Jardins in 2005 and which was acquired in 2014. She is co-author of Road Map for Revolutionaries: Resistance, Activism, and Advocacy for All, writes the weekly Buffy Life Lessons newsletter, hosts courses on LinkedIn Learning and GenConnect U, and advises mission-driven leaders and organisations. She now product manages her own AI-powered tools into existence and teaches other people to do the same.

About the host

Rob Woodhead is a co-founder of Old.St Labs, a London-based AI software development agency building web and mobile products for startups and scale-ups. He hosts The Humans Behind the Tech.

Frequently asked questions

What is the difference between vibe coding and vibe product managing?

Elisa Camahort Page argues that most people who say they vibe coded something actually vibe product managed it. They set requirements and made product decisions while the model wrote the code. The distinction matters because product judgement and code quality are separate things, and a prototype can prove the first while saying nothing about the second.

How should someone start using AI at work?

Elisa's advice, which she credits to writer Alexandra Samuel, is to start with something fun and low stakes where a mistake cannot damage anything. Her own first projects were a curriculum to relearn tarot and another to learn Spanish.

Why do AI rollouts fail inside companies?

Elisa's argument is that leadership frames it as efficiency, which employees correctly hear as replacement. She recommends deciding first how you want people in the organisation to learn and advance, then asking how AI supports that, and using formats like hackathons so people can solve their own small frictions.

Can you stop an AI model from being sycophantic?

Elisa has instructed Claude never to write for her, to ask questions rather than produce copy, and to flag when a phrase is framing rather than fact. Her broader point is that the model reflects the framing you give it, so the instructions you set are doing most of the work.

Does it matter if writing was produced with AI?

Elisa's test is not detection but accountability: can the person back up what was written, answer questions about it, and explain how they reached the conclusion. She is sceptical of AI detection tools and expects them to be used unfairly against people who are already scrutinised more closely.