In the Author Spotlight series, TDS Editors chat with members of our community about their career path in data science and AI, their writing, and their sources of inspiration. Today, we’re thrilled to share our conversation with Dr. Janna Lipenkova.

Dr. Janna Lipenkova is an AI strategist, entrepreneur, and author of the book The Art of AI Product Development. With a PhD in Computational Linguistics, she combines deep technical insight with business strategy to help organizations turn AI into tangible outcomes. Janna has founded and led multiple ventures at the intersection of language, data, and intelligence — including Anacode, which focuses on enterprise AI transformation, and Equintel, an AI platform that supports corporate sustainability. Through her thought leadership and consulting activities, Janna is continuously shaping and refining her comprehensive methodology for AI development and integration. 

You call your “AI Strategy Playbook” a set of mental models that help teams align on what to build and why. Which models most often unlock clarity in executive rooms, and why do they resonate?

One of the biggest challenges in executive rooms is communication. People mean different things when they talk about AI, which blocks execution. I use three mental models to create a structured common ground which allows us to move forward without excuses and misunderstandings.

I usually start with the AI Opportunity Tree, which helps us map the landscape of possible AI use cases. Executives often come in with a mix of curiosity and hype — “we need to do something with AI” — but not a clear view of where value really lies. The default path most teams take from there is building a chatbot, but these projects rarely take off (cf. this article). The Opportunity Tree breaks this pattern by systematically uncovering potential AI use cases and providing a structured, objective basis for prioritization. 

Once we have clarity on what and why to build, we move to the how and fill out the AI System Blueprint. This model helps map the data, models, user experience, and governance constraints of the envisioned AI system. It’s especially powerful in multi-stakeholder environments, where business, data science, and compliance teams need a shared language. The blueprint turns the complexity of AI into something tangible and iterative — we can draw it, discuss it, and refine it together.

Finally, I introduce the AI Solution Space Map. It expands the conversation beyond today’s dominant technologies — mainly large language models and agents — and helps teams consider the full space of solution types: from classical ML to hybrid architectures, retrieval systems, and rule-based or simulation-driven approaches. This broader view keeps us grounded in delivering the right solution, not just the fashionable one.

Together, these models create a journey that mirrors how successful AI products evolve: from opportunity discovery, to system design, to continuous exploration. They resonate with executives because they bridge strategy and execution.

In your writing, domain expertise is important in building AI products. Where have you seen domain knowledge change the entire shape of an AI solution, rather than just improve accuracy at the margins?

One vivid example where domain expertise completely reshaped the solution was a logistics project initially started to predict shipment delays. Once the domain experts joined, they reframed the problem: delays weren’t random events but symptoms of deeper business risks such as supplier dependencies, regulatory bottlenecks, or network fragility. We “AI experts” were not able to spot these patterns. 

To incorporate this domain knowledge, we expanded the data layer beyond transit times to include supplier-risk signals and dependency graphs. The AI architecture evolved from a single predictive model to a hybrid system combining prediction, knowledge graphs, and rule-based reasoning. The user experience was expanded from reactive delay forecasts to risk scenarios with suggested mitigations, which were more actionable for experts.

In the end, domain knowledge didn’t just improve accuracy, but redefined the problem, the system design, and the value the business received. It turned an AI model into a true decision-support tool. After that experience, I always insist on domain experts joining in during the early stages of an AI initiative. 

In addition to your posts on TDS, you also wrote a book: The Art of AI Product Development: Delivering business value. What are the most important takeaways that changed your own approach to building AI products (especially anything that surprised you or overturned a prior belief)?

Writing the book motivated me to reflect on all the bits and pieces of theoretical knowledge, practical experience, and my own conviction and structure them into reusable frameworks. Since a book needs to stay relevant for years, it also forced me to distinguish between fundamentals on the one hand, and hype on the other hand. Here are a couple of my own learnings: 

• First, I learned how to find business value in technology. Often, we oscillate between two extremes — either chasing AI for the sake of AI, or relying solely on user-driven discovery. In the first case, you are not creating real value. In the second case, who knows how long you’ll have to wait for the “perfect” AI problem to come to you. In practice, the sweet spot lies in between: using technology’s unique strengths to unlock value that users can feel, but wouldn’t necessarily articulate.We know it from great innovators like Steve Jobs and Henry Ford, who created radically new experiences before customers asked for them. But to do this successfully, you need that magic mix of technical expertise, courage, and intuition about what the market needs.
• Second, I realized the value of user experience for AI success. Many AI projects fail not because the models are weak, but because the intelligence isn’t clearly communicated, explained, or made usable. The success of an AI product depends on how intuitively users can interact with its capabilities and how much they trust its outcomes. While writing the book, I was rereading the design classics, like Don Norman’s The Design of Everyday Things, and always asking myself — how does this apply to AI? I think we are still in the early stages of a new UX era. Chat is an important component, but it is definitely only a part of the full equation. I am very excited to see the development of new user interface concepts like generative UX. 
• Third, AI systems need to evolve through cycles of feedback and improvement, and that process never really ends. That’s why I use the metaphor of a dervish in the book: spinning, refining, learning continuously. Teams that master early release and constant iteration tend to deliver far more value than those who wait for a “perfect” model. Unfortunately, I still see many teams taking too long before delivering a first baseline and spending not enough time on iterative optimization. These systems might make it into production, but adoption will likely not happen, and they will be shelved as another AI experiment. 

For teams shipping an AI feature next quarter, what habits would you recommend, and what key pitfalls should they avoid, to stay focused on delivering real business value rather than chasing hype?

First, as above, master the art of iteration. Ship early, but do it responsibly — release something that’s useful enough to earn user trust, then improve it relentlessly. Every interaction brings you new data, and every piece of feedback is a new training signal.

Second, keep a wider outlook. It’s easy to get tunnel vision around the latest LLM or model release, but the real innovation often comes from how you combine technologies — retrieval, reasoning, analytics, UX, and domain logic. Design your system in a modular way so you can extend it, and continuously monitor AI solutions and developments that could improve it (see also our upcoming AI Radar). 

Third, test with real people early and often. AI products live or die by how humans perceive and use them. Internal demos and synthetic tests can’t replace the messy, surprising inputs and feedback you get from actual users.

Your long-form writing (book, deep dives) avoids hype and centers on delivering value to organisations. What’s your approach for choosing topics and does writing about these topics help you better understand them? 

Writing has always been my way of thinking out loud. I use it to learn, process complex ideas, and generate new ones. I usually go with my gut and write about approaches that I truly believe in and that I’ve seen work in real organizations.

At the same time, at my company, we have a bit of our own “secret sauce.” Over the years, we’ve developed an AI-driven system for monitoring new trends and innovations. We provide it to a couple of select customers in industries like aerospace and finance, but of course, we also use it for our own purposes. That blend of data and intuition helps me spot topics that are both relevant now and likely to matter not only in some months, but also two or three years down the line.

For example, at the start of 2025, we published a report about enterprise AI trends, and almost every theme from it has turned out to be highly relevant throughout the year. So, while my writing is intuitive and personal, it’s also grounded in evidence.

To learn more about Janna‘s work and stay up-to-date with her latest articles, you can follow her on TDS, Substack, or LinkedIn.