About
Jani Rostoll
If you are running a business and you have a software idea — or something needs to change but the path is fuzzy — you care about outcomes, not jargon: whether the idea is worth pursuing, what to build first, and how to brief a developer without owning technical detail you should not have to own.
That is the work I help with. I use story mapping — a simple way to describe the journey people take when they use your product: what they are trying to get done, step by step — instead of a long shopping list of features. When you keep that story in view, you stay closer to your customers and your business goals. When you lose it, software projects often turn into arguments about features that never quite land.
When you work with me, you get more than a decade of product and design judgment built on live business systems — knowing which framework fits which problem, generating the right questions and a clear "build this, not that" direction, not just outputs. Applied in a focused engagement to your idea and your timeline.
My background is design — how people actually use software at work (often called user experience: whether the product fits the job, not only how it looks), mostly business software and internal tools. I moved into product management because the same questions kept returning: What matters first? What can wait? How do we say this so everyone — including you — can agree? I lead product on large, business-critical software full time. I take focused, time-boxed engagements with select SMBs: discovery to clarify the problem and what should come first, a written brief or specification your developers can estimate from, a prototype when we need to validate the core workflow before you spend on build, and handoff to your development partner when you are ready to implement.
I am based in Ballito, KZN, and work mainly with South African SMBs. I am happy to talk if you are further afield and there is a fit.
Perspective
Why product management and design experience together
Design and product management answer different questions; together they keep the work grounded in how people work and honest about priorities. That is what the discovery-to-handoff process above is for — not paperwork for its own sake.
Plain language, real decisions. You should understand what we are proposing and why, in words that fit your business — not a textbook. The goal is alignment before build: everyone sees the same story of what we are building and for whom, so estimates and trade-offs mean something.
Sensible use of budget. AI tools can generate software fast. Building the wrong thing fast is still expensive. Figuring out the right direction before you build is almost always cheaper than building the wrong thing twice. I am upfront about what we know, what we are guessing, and what we would test next — so you put rands into development when the direction is validated, not when we are still guessing.
Principles
How I show up
- You stay in charge — I help you get to clarity and language you can use with stakeholders and developers; I do not run your business or replace your decisions.
- Focused work, clear boundaries — Engagements are scoped (discovery, spec, prototype, handoff) alongside my day job — so you know what you are buying and for how long.
- Build is not my bench — When you are ready to implement, I help you transition to a development partner; I stay generic about names on the public site.
Scope and fit: For what I take on and what I do not offer as services (retainers, engineering, and the rest), see Services