Bespot · Product internship
Owning a new product, supporting an existing one, and building an internal system from scratch
I owned a new product from market research through to shipped user stories, supported the existing product, and designed and built an internal improvement-request system end to end, including the prioritisation model behind it.
Why this internship gets a full page
I worked directly with the Lead Product Manager on strategy and decisions for both the existing product and a new one, was made primary owner of that new product, and shipped an internal system that the product team then used to decide what to build next.
1. The internal system I built end to end
People across the company had ideas about how to improve the product and the way we worked, but the way of capturing them was not effective. The Project Manager wanted a new system that would not just do that work more effectively, but increase the number of requests coming in, which meant the system had to actually attract the employees using it far more than the old one did. Building it was assigned to me and I delivered the whole thing: three subsystems covering collect, evaluate and visualise, with extensive feedback from the end users throughout and a study of how similar solutions handle the problem.
Collect
A form built mostly around targeted questions, so that most of every submission arrived structured enough to be evaluated, plus one open field where the user described the idea or problem in their own words. Submitting stored the request and automatically triggered the next stage.
Evaluate, using a custom prioritisation model
There are established models for this, including MoSCoW, RICE and WSJF. I studied them and none fit the specific needs of this project cleanly, so I built a custom model combining variables from several of them, had it approved by the Product Manager, and applied it to every request. The four variables were:
| Variable | What it asks |
|---|---|
| Impact | If we did this, how much better does it actually get? |
| Effort | What does it cost us to build? |
| Reach | How many people does it affect? |
| Urgency | Does delaying this cost us something? |
Why not simply use RICE
I did not build a custom model out of a preference for building things from scratch. The Product Manager had already told me what he wanted to know quickly about each request, and what should weigh most when judging one, so I had a clear brief to follow rather than a blank page. That brief is what led to the blend of variables above: built for what mattered to us, so the visualisation that followed could foreground exactly that.
Visualise, with four dimensions on one chart
Once evaluated, a request was automatically placed on a four-dimensional bubble chart. Each variable maps to a visual property, so the prioritisation can be read at a glance rather than sitting in a spreadsheet nobody opens.
| Dimension | How it's drawn |
|---|---|
| Reach | Bubble diameter, so a bigger bubble means more people affected |
| Effort | X axis, so the less effort required the further left it sits |
| Impact | Y axis, so the more impact it has the higher it sits |
| Urgency | Colour: green for low, blue for medium, red for high |
The result is a chart the product team could read in seconds. A bubble that is top-left, large and red has high impact and wide reach, is urgent, and costs little to build, making it a quick and significant win. That single reading rule is why the chart was adopted.
A public dashboard, so nothing was lost
Every request also appeared on a public kanban board whose status updated automatically as the request moved through submitted, under analysis, in backlog, in sprint and done, plus for later and rejected. Each time a request changed state, the person who submitted it was notified and could follow the progress themselves.
Where feedback insights unlocked the way to satisfy the business needs
The public kanban was not in the original brief, it came out of the feedback I collected from users during the project. Several people told me one of the biggest reasons they had stopped submitting new requests to the old system was that they never knew what happened to the ones they had already sent, and felt like they got little back even when their idea did lead to a real change in the product. That was the answer to the business need behind the whole system: collect more requests, and get employees actually using it. The kanban and its notifications solved exactly that: users could see where their request stood at any point, and watching it move gave them a sense that it was being taken seriously and was actually shaping the product, which is what brought people back to using the system.
2. A new product I owned
The product was an in-app feedback collection system. After a user completed specific actions in the client's application, it captured what they thought while the experience was still fresh. I was assigned as primary owner.
The work, in the order it happened:
- Extensive market research. I looked at how other companies already solve this and built real domain knowledge before forming an opinion, because an opinion formed too early is hard to move away from later.
- A catalogue of competitor features and capabilities, followed by the harder step of deciding which of them actually fit our case rather than copying the longest list.
- A minimum feature set assembled from that analysis, covering the smallest version that would genuinely work.
- Value-adding features on top, chosen from user research rather than from the competitor list. This is what decides whether a product is a copy or a deliberate choice.
That analysis became the basis for the Product Documentation, which I co-authored with one other person, creating the BRD and the requirements behind it. From those documents I produced the user stories in Jira and assigned them to the relevant teams, which is the point where the product stopped being a document and started being built.
From there I followed development closely to support the team, made the necessary modifications during backlog refinement and sprint planning, and kept the documentation updated as the product changed. The team ran full agile Scrum and I took part in every ceremony.
3. The existing product
Bespot's established product precisely tracks customer location inside retail stores. My role here was supporting rather than owning, with a specific responsibility: to know the product and the market well enough to propose modifications and optimisations, not only to process the ones handed to me.
A few additional responsibilities came with that:
- Backlog refinement for the product, and writing new user stories.
- Sprint monitoring.
- Working closely with the team to resolve questions and bridge business and technology, which is largely about making sure both sides mean the same thing by the same word.
- Taking part in demos, then structuring the conclusions from client feedback and discussing them with the Product Manager to identify where we could improve and what should change.
What I took from it
- User feedback can hand you the business need, not just a symptom to patch. The public kanban did not come from a spec, it came from users explaining why they had stopped using the system at all.
- Make the decision visible. The same four numbers in a table would have been ignored. On a chart with one clear reading rule, they were used.
- Do the market research before forming an opinion. This is the habit that later shaped the competitor matrix at OptimaLifts and the competitive audit at EzyFlat.
- A prioritisation model has to reflect what the decision-maker already values. Getting it explicitly signed off before applying it was worth more than any further refinement to the formula.