Product Manager

About SleekSky

SleekSky builds and runs software for clients who want to scale their technology without heavy overhead. We work in dedicated teams with a startup-inspired culture and a bias for agility, ownership, and continuous improvement. We combine professional depth with real room to learn, decide, and build things that last.

The role

Most product roles at three to five years hand you a backlog to groom and a roadmap someone else set. This one hands you part of a live product and asks you to work out what should happen to it.

You'll own areas of a healthcare platform we build and run for a US client, with real organisations using it all day and real patients on the other end. A problem might arrive as a complaint, a number that moved for no obvious reason, or an operations team doing something by hand forty times a day. You take it all the way:

• Work out what's actually happening
• Decide whether it needs an answer, a fix, or a change worth making
• Write the requirement engineering builds from
• Stay with it while it's built
• Go back and check it did what you said it would

It's part product management, part customer engineering, and part sitting with data until it tells you something. It's wide on purpose.

What you'll own

• Areas of the product, end to end. You decide what happens next in a part of a live platform, and you're answerable for whether it was worth doing.
• The customer's problem, from complaint to diagnosis. Our customers are large US healthcare organisations, and their problems arrive as complaints, not specifications. Working out what's actually wrong is yours before anything else happens.
• The requirement engineering builds from. Written down, with product decisions made and engineering decisions deliberately left open, so engineers can start without you in the room and know which questions are still yours.
• The numbers, watched rather than reported. Nobody sends you a dashboard each morning. Knowing what normal looks like, noticing when it stops, and finding out why before a customer tells you is part of every day.
• The decision about what not to build. More requests arrive than can be built. Deciding which ones don't get built, telling the person who asked, and defending the ranking is the hardest part of the job and the one that matters most.

What you'll bring

• 3–5 years in product management, or an adjacent role where decisions were genuinely yours: business analysis, solution engineering, customer success with real product influence, or engineering where you owned the what as well as the how.
• Curiosity that goes past the interface. The strongest people here go and look at the data, the logs, the actual records, and the person doing the work, rather than asking someone to explain it. This is what we screen for hardest, and it's the thing we can't teach quickly.
• Writing other people act on: a spec, a decision memo, an incident write-up.
• Comfort in front of an unhappy customer, and the instinct to find out what's actually wrong before agreeing to anything. "I don't know yet, and here's when I will" is worth more than a fast answer.
• Enough SQL or spreadsheet fluency to answer your own questions instead of waiting on someone else.