Bringing an Idea Into a Tangible Tech Product

So you just came up with the next big app idea to hit the market since Uber…and lucky for you, you’re friends with a software developer who is actually going to spend their precious free time to help you build it. Fantastic.

Note: This is a rare occurrence and although not widely known, most developers also have great ideas they are working on and will more than likely not want to build yours. So if you need to hire someone, try here, or here.

Perhaps this is the first time you’ve actually worked with a developer and are unaware of the fact that you can’t just tell them, “hey, build me an app that let’s people order dinner from an amateur chef’s home kitchen” without actually spelling out the various requirements you want to see in the application. So if this is the case, sorry it’s not that easy, but we’ll get there…

What you do need to do is be able to provide your developer with a prioritized feature “to-do” list, or what we call in Agile, a Product Backlog. The goal here of the product backlog is to break the big-picture vision of your app down into manageable increments that can be executed by a developer.

Think about if your boss just asked you to put on a global conference for all employees in your company. This is a huge task, but with some thought can be broken down into smaller, more actionable items like: Hire a keynote speaker, Cater lunch, Set the conference agenda, etc.

User Stories
The way to organize each “to-do” list item in your product backlog is in the form of a User Story. User stories are simplified requirements that are used to capture a description of a software feature from an end-user’s perspective.

For user stories stories we use this basic format in Agile:
As a <type of user>
I want <some goal>
So that <some reason>

Here’s a real life example of a user story I’d expect to see from Facebook (circa 2006):

As a logged in user
I want to post a photo to my profile
So that my friends can view it and see what I am up to

The <type of user> in this case is a user of Facebook that has successfully logged into the application. When writing your user stories, it is important to accurately define the user type, or “personas” as they are commonly referred to, so the developer knows who should have access to this feature.

The <some goal> of this feature is to allow users to post a photo to their profile. Here we are describing the action the user is doing in the application.

The <some reason> in this story is that your friends can view it and see what you are up to. This is often the value proposition of the feature. Tip: If you are having trouble with this part of the user story, there is a chance that this feature is not as important as you once thought and may want to consider not including it and/or de-prioritizing it.

Massive user stories, like the example I gave of setting up a global conference, are considered ‘Epics’. Epics are not ready to be executed and require further refinement into smaller user stories over time. It’s ok to include these in your backlog as a placeholder, but understand that developers will not be executing them as the requirements are not yet defined.

An example of an Epic user story for Facebook (prior to launching an app) would be:

As an iPhone user
I want to view Facebook in a native iOS app
So that I can stay informed on the go

Acceptance Criteria
So you have your user story written out, but as Charles Eames (creator of the Eames chair) famously said, “The details are not the details. They make the design”. If presented with just the user story about posting a photo (and no additional context) you will be flooded with follow up questions by your developer…

So where in the app can the friend view the photo (news feed, profile, etc.)?
Can the user add a text caption? If so, how does the caption appear?
What happens when a user clicks the photo? Does it enlarge?
Can friends comment on the photo?You get the point.

In order to provide more clarity, we like to enrich our user stories with what is referred to as Acceptance Criteria.

Acceptance Criteria are the conditions that a software product must satisfy to be accepted by a user.

I personally like to use the GIVEN/WHEN/THEN format as it provides a scenario for the developer to easily understand (and later test). Here’s an example of some of the acceptance criteria I’d expect to see for the Facebook story we used above:

GIVEN a logged in user is on their profile page
WHEN the user clicks the photo icon
THEN the user is prompted to upload a photo

GIVEN a user is prompted to upload a photo
WHEN the user selects the photo from their files AND selects the Post button
THEN the photo will appear AND allow the user to add a caption

GIVEN a logged in user is friends with the user that posted a photo
WHEN the user is on their news feed
THEN the photo will appear and display the caption (if added)

GIVEN a user views a photo in their news feed
WHEN the user clicks on the photo
THEN the photo will enlarge to the original size

As you can see, this begins to clarify how the feature will be implemented and what behavior you expect to see once it is. Be sure to get into the details here as it is how you want others to ultimately use your product.

Prioritization
It’s expected at the end of the user story exercise that you’ll have a laundry list of features in your product backlog. While this is great, and means you’re full of ideas, your developer can’t build them all at once and will look to you to prioritize each feature to be built. This simply means putting the most important feature on the top, and working your way down to the least important. I really enjoy this phase as it makes me think through the real value of each.

If you are building an MVP, minimum viable product, you may just choose the 20 or so “must-have” features to bring to market, then roll out the others over time in various versions.

Handing over the backlog
You did it. You’ve created your list of the must-have user stories to bring your app to market, each with detailed acceptance criteria explaining how you want to see them implemented.

I personally like to organize my backlog in a Google Sheet and share it with my developers. They of course will have plenty of questions throughout the development process and using a collaborate tool like Sheets helps keep the backlog as a living document.

You can also use a more sophisticated paid tool like Jira or Rally, which will help you further organize and manage the development of your feature list.

If you want a free and more DIY solution to track the development process, you can also use Trello (which has a free app too).

Prototyping (Bonus Points)
If you’re the creative type who wants to control more of the look and feel of your product, I suggest going the extra mile and building a simple prototype (or mockup) to accompany your product backlog. This will give the developer support in the visual representation you desire and not force them to interpret your written user stories alone.

A few tools I like to use:

1. InVision — this is for the more detailed approach and allows you to really build out the visual representation and workflow of the product.
2. Balsamiq — this is a more low-fi option, but is useful when it comes to placement of features within the product.

So What’s Next?
​Now that your app development is in motion, it’s time to for you to think about the future and build out your product roadmap (how you expect your app to evolve over time).

Eric Rems
Co-founder, The Mindful Tech Lab - Check out all of our amazing apps to help improve your life here
​