Our Product Process

In a first step we collect issues from all sources available. Many are discussed and compared against another, and shortlists are created. 

We then prioritize based on cost and impact, often preferring strings of smaller improvements that have good impact on many customers each, and that can be marketed together.

But sometimes a full feature-rewrite can be more efficient and reduce tech debt too, so it really depends on the cost-impact assessment each time.

Most of the practical work happens in Linear issues, larger discussions in our weekly PM meeting.

For bugfixes and obvious changes we merely create a Linear issue, get some comments from stakeholders, and put the Linear issue into a manually groomed priority  queue.

Developers can pick freely from this list, taking into account their skill level, their familiarity with the topic, their interest, and also their time availability. On Friday afternoon it may make more sense to pick something easy and low on the list, on Monday morning something more demanding.

Oftentimes complex tasks are broken into easy tasks, so a larger project might start with one developer, but gets split up so everyone who is keen can contribute by working on subtasks.

For medium sized tasks, we prefer a bit more structure. Typically, a PM will create a mini-spec (“Challenge – Proposal – Considerations”) including some mocks, and ask developers and customer-facing staff for feedback. The PM might also create a clickable prototype in Figma or (more recently) using Claude.

A developer then picks it from the queue. Mocks and Prototypes are to be seen as inspiration, not final product. So a developer will aim for a minimalist version  for internal testing, refining the spec together with PM as they go. 

Once deployed to a testing system, other stakeholders will take a look, and the feature gets some more updates, usually just using Linear tickets. The next step is to share a MVP with initial customers via our in-app Early Access Program and gather feedback from them too. 

Then, maybe 2-4 weeks later, the feature gets released properly. It’s announced on the release notes, it’s marketed inside the product, and gets a mention on the bi-monthly product-newsletter.

Depending on how minimalist the first version was, we might start work on a 1.1 version immediately, or it can make sense to wait a few weeks while customer feedback rolls in. 

Large tasks are technically no different than medium ones, but we spend more time validating. The last thing we want is to build a feature customers said they wanted, but then don’t actually use. Or if they find it lacking, and the extra work would be enormous. 

So the first step is to create a customer-facing spec, something that describes our goals in sufficient detail and clarity that customers can assess if they even find it useful. We’re very clear about limitations of the feature we’re building, so they can object in time.        

We share the specs widely, get as many customers on the phone as possible, and try to assess their engagement level, also using clickable prototypes or code-based prototypes, and writing “future marketing material” to ensure it all fits.

Work is even more incremental than with mid-sized features, but generally follows a similar approach from here-on.

And that’s a wrap! You can learn more about our how we develop, about our team in general, and about our values and work ethos.  And if you’re interested to work with us, please proceed to our Senior Developer Job Ad over here! 

All the best from the PM Team @ SI