GiftBot – Our Product Management Training Project

As part of the Product Management training at General Assembly I worked with two other Product Managers to go through the product process of identifying a problem, doing user research to understand and define the problem, identify our riskiest assumptions and run an experiment to test it, create an MVP to test whether we can solve the customers problem, and iterate upon the feedback.

The Problem

Busy people forget or run out of time to buy gifts for friends and family.

Lean canvas

We used a Lean canvas to record our assumptions to help us identify the riskiest for validation.


After undertaking research with 18 people we grouped their responses together to allow us to create personas.


The first version of GiftBot:

This version received an NPS score of 5.9.

GiftBot after user testing received feedback that it wasn’t very friendly and returned too many results. This version scored 7.2.

Final presentation

GiftBot Presentation

Velocity as a measure for products not teams

I’ve been thinking about velocity as a measure for teams and products. The definition of the word is ‘the speed of something in a given direction‘, not just speed as we often think.

Scrum measures velocity, defined as “the amount of work a Team can tackle during a single Sprint … is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories”, as speed alone. USpS is the MpH of the team, it is ‘output velocity’.

So, in this way of thinking, velocity is a team performance metric. It’s narrow, used to understand only the speed of the team, and doesn’t include the direction element from our dictionary definition. The issues that we see with using USpS to measure team speed alone is that the team could easily be moving quickly in the wrong direction (I guess the assumption in Scrum is that direction is provided in other ways), and that measuring human beings in such a mechanistic way is fraught with all kinds of inequalities, assumptions, and biases to the point where it becomes more damaging to the team than it is helpful.

But that doesn’t mean we have to abandon velocity all together. There are other ways of thinking about it as a useful measure. We could define velocity more broadly as ‘speed in the right direction’. Then, this ‘impact velocity’ could be used more to understanding the performance of the Product as it advances towards its goal state, rather than the team as in Scrum. The same team can measure impact velocity across multiple Products, and compare them, and learn from each other.
So, why measure impact velocity at all? If ‘velocity = speed in the right direction’, then the reasons to measure it are to check direction and course correct, and the sooner this is done because there is pace in achieving goals the more likely the team are to achieve mission.

Quality has to be part of our definition of impact velocity, and something that Scrum seems to be criticised for lacking and the resultant shipping of bugs just to get as many user stories completed in that sprint. Velocity is speed in the right direction, not just speed, so quality along the way; quality thinking, quality customer insight, quality deciding, quality building, quality shipping, quality feedback, provide the team with the ability to correct the course of the products and head in the right direction with more speed.

At least now I have a bit of a working definition that I can use to think about and test was of measuring impact velocity on real products.

Highlights from “Observations on Product Management” by Dan Hill

Highlights from “Observations on Product Management”

” The job of Product Management is to deliver good products to end users. The sheer number of possible definitions of good, product and user mean there’s no standard look to a Product Manager. But if you don’t deliver, the product is not good, or no-one uses it, you’ve done it wrong.”

” There’s good process and bad process. Good process is any that allows the team to produce better work faster, with joy and elegance. Bad process is anything else.”

” Incremental development and vision are not orthogonal; they both require the other. All product must start with a vision — a point of view — but then be built critically step by step. It’s ok to learn something new as you go.”