Knowledge Architect and Product Enablement Expert

Company Description At Docplanner Group, we’re on a mission to help people live longer, healthier lives. As the world’s largest healthcare platform, each month, we connect 24 million patients with 280k doctors across 13 countries (through brands like ZnanyLekarz, Doctoralia, MioDottore, DoktorTakvimi, and jameda).

Our marketplaces, SaaS and AI tools simplify daily tasks and help doctors, clinics and hospitals work more efficiently, so they can focus on what really matters: caring for their patients. Learn more about our products here: pro.doctoralia.es Why join us? Real impact – We help doctors help patients. Your work truly makes a difference.

At scale, yet agile – 3,000+ employees, but still fast, flexible, and hands-on. ✨ Shape the future, sustain growth – Make a difference now and build for long-term success.

What you will own The structure of our product knowledge Define and keep the content model for Docplanner product knowledge : small self-contained facts, how topics are organised, which labels and metadata we use, and what belongs to the internal knowledge base versus the external one for customers and doctors. Set the quality standard.

Every fact carries a reference to where it came from (repository, file, place in the code), so anyone can check it again later instead of trusting it blindly. Choose one structure that works for both assistants, Kraken for customers and Noa for doctors, so we do not end up maintaining the same knowledge twice. Getting knowledge out of the code Work directly in GitHub with read access to the monorepo and the other repositories.

Find where the logic of a feature really lives , read it well enough to understand the rules and the special cases, and turn it into clear output that other people can review . Improve the way we generate this output, so that over time fewer facts need a person to confirm them. Simplifying is key . Protect one rule: every new or changed feature is generated from the code from day one.

Older content is only redone when a release touches it, or when it is one of the most used topics in Kraken and in Customer Care. We are not going to rewrite the whole knowledge base in one big project. Our current internal knowledge base Review what we have today, article by article, and decide what happens to each part: move it to the new structure, rewrite it, replace it with output generated from the code, or archive it because it is no longer useful.

Propose the order of that work, with clear reasons based on how much each topic is used and how often it changes, and agree with the manager of the team. Lead the team through that work. You do not do it alone. You decide the method, you explain it, you review the result, and you keep the quality consistent across markets and people . Teaching the team to work in the new way Bring the team from writing articles to checking facts .

This is a real change in habits, and it needs to be taught. Create the working guides, examples and short training sessions that make the new way easy to follow, and update them as the method changes. Build new skills inside the team : how to write a small self-contained fact, how to review generated content, how to spot a knowledge gap, how to work with content that lives in a repository, and how to test an AI assistant's answers.

Be the person the team asks when they are not sure . Answer, and then write the answer down so the next person does not have to ask. The facts that are not in the code Identify the types of knowledge that the code simply does not contain : differences between markets and plans, the wording on screen, what the patient sees, screenshots.

For each type, design a way of getting that information that we can repeat every time, together with Product Managers, Product Marketing and Product Experts. Run the review loop with the people who own each feature. Prepare the facts in a format that a person without a technical background can confirm, correct or reject quickly. Keep track of what came back wrong, and why.

Keeping knowledge up to date Define how the knowledge stays current with dozens of releases every month: what triggers an update, who is alerted, and how fast we commit to make the change. Warn the Help Center team when a release makes published content wrong, and be precise enough that they can fix it without reading the whole article again. Working with the rest of the chain Product Experts feed, test and improve the internal knowledge base.

You make it easy for them to give input, and you keep them in the role of people who check facts rather than write them. The Help Center team publishes and maintains the content for customers, using your output. You own the format you hand over and the alerts you send. They own publishing. The owners of Kraken and Noa use your output. You agree with them what they receive, and you test the quality of the assistants' answers against a fixed list of questions.

Engineering for access to the repositories, for the monorepo