Grow Up and Prototype

As a Project Manager at a company that manages the software development lifecycle for a variety of clients, my personal agenda for the weekend was to use the strategy, definition and development processes that Applico uses and see if they could be tailored towards Service Design. Since Applico also places a high emphasis on building a Minimal Viable Product (MVP) for clients, another goal was to utilize lean methodology and the principles of service design to meet the following objectives:

• Define the minimum feature set to address the right set of problems

• Engage users and get feedback throughout the product development cycle

• Build and receive feedback on prototypes to challenge product and market validation in parallel using short iterations

After learning about the super-secret Service Design Jam theme (Grow ^), our first idea was aggregating wisdom over the internet. After countless iterations through the weekend, we ended up with the concept of providing individuals with convenient, free tech support……. Quite a pivot!

Below are some of the deliverables and the processes that Applico employs and how our team tweaked these to meet the goals I outlined above:

STRATEGY

At Applico we utilize the Business Model Canvas, a strategic management template for developing new or documenting existing business models. We tweak the standard model in favor of Running Lean by Ash Maurya, which can be seen below. We use this model because it places a higher emphasis on problems informing the solution, rather than thinking of solutions to problems that don’t exist – a trait of many startups. Throughout the weekend this canvas evolved as we refined and improved our idea.

IDEATION

After realizing that our initial idea had too many competitors (two small companies called Google and Facebook to name a few), we brainstormed concepts and discussed the idea that there was a large percentage of the elderly population who need help with their tech problems. We went into the field to interview elderly people to support this idea. For example, we spoke to an 83 year old woman who taught herself how to use a computer so she could write documents for her local church. For the first 5 years of her computing experience, she had a habit of accidentally hitting a series of mangled keystrokes that resulted in Select All and deleting her work. Each time she was devastated, but would start over and rewrite from scratch. Then one day someone taught her CTRL+Z (undo). Her life was changed.

Interactions like these provided us with our company name (Control Z) and helped validate our vision.

PERSONA CREATION

We created a variety of personas who would potentially want to use the service. This helped us understand the values and needs of our users and competitors. We went back into the field to talk to a variety of people about volunteering and using a service like this, in addition to going to stores such as Best Buy to see how other businesses provide Tech-Support-as-a-Service.

USER STORIES

Creating user stories in the tech world is the same as creating requirements for any product/service. The objective behind structuring the requirements like a user story is that stories are written in the following format: ‘As a [persona], I can [activity] so that [reason]’. Following the user story structure meant we were creating a service that was made for the benefit of the customer, not the service provider.

USER FLOWS

In the offline world these are known as customer journeys. We examined the potential paths that users may flow through when using the service, which helped us dig deeper into the structure of the service.

We created storyboards demonstrating how our personas could use the service, which we acted out and filmed. After watching the videos, we examined and highlighted the touch points throughout the system (a touch point is any time there could be an interaction between the user and the service). We discussed flaws in these touch points and how they could be improved.

We performed this process several times over the weekend, particularly with non-team members, whose objectivity provided valuable insights.

WIREFRAMES, STORYBOARDS & PITCH

A combination of concepts/personas/user flows, we sketched out the scenes that would ultimately become our video pitch.

The sketches and video pitch introduced 2 personas that we had created: a user of the service (Ted) and a volunteer at the service (Jill). We mapped out a storyboard about how both came to use the service, culminating in a magnificent symbiotic relationship that benefited both of them…hooray!

The video pitch was the final deliverable of the weekend, and was to showcase your product to the whole world wide web. We were a few hours late and received a stern Skype call from the Service Jam founder…

CELEBRATE!

Ok so this isn’t officially part of Applico’s process, but we’re pretty good at letting our hair down after working hard and making RIDICULOUSLY awesome products.

CONCLUSION

Since I have managed a variety of agile projects, the focus on creating prototypes to establish, validate and ultimately accept/reject ideas and make continuous improvements wasn’t a revolutionary concept to me. However, my big takeaway from the weekend is that app development firms should be trying to get prototypes into the hands of users as early as possible in Product Definition. Applico has recently started creating clickable mockups and we are talking to clients about user testing in Product Definition – I would like to see us do more of this and prototype even earlier by doing clickable wireframes. Stay tuned folks as I look to completely change things round ‘ere at Applico.

Finally, validating my theory that the processes used by an app development company could be transferable to any startup was also a great feeling, and will be an anecdote I tell to any naughty Product Manager or client who tries to cut corners and break process from now on!