that can get to a shippable version 1 quickly • that solves a problem people will pay to have solved • that does not need a lot of traction to be useful • that has existing competition A product ... Friday, 18 April 14
start with the end-goal in mind, then divide it into smaller and smaller increments. Plan all of the actions in detail beforehand, then get to work.” Friday, 18 April 14
• At launch we were still 100% booked out on client projects • Income from Perch was initially reinvested into Perch • January 2013 we made the decision to stop taking on new client work Our timeline Friday, 18 April 14
use cases not feature requests • Delight customers by solving problems • Protect the core use case • Make frequent, small releases • Don’t be led astray by a noisy minority Friday, 18 April 14
be flexible and react to customer needs and changing trends in web design. • It means that customers are not relying on the launch of feature X in order to complete a project. • It means that we can hold back a feature until we are absolutely sure it won’t cause anyone a problem. Friday, 18 April 14
wrong • Easier to isolate the issue if a problem does occur • Get features to customers more quickly • For our customers, less of a dramatic change that they need to communicate to their clients Friday, 18 April 14
a landing page and email signup form • About 500 people signed up • We emailed the list on launch and those people represented enough sales on launch day to pay back all pre-launch costs. Friday, 18 April 14