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.
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
<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
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.
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:
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). We’ll get to that next time!
This is part 1 of the “Idea to Product” series I’ll be working on. Keep in mind this is just a primer for anyone looking to leverage Agile development techniques and by no means is meant to be all encompassing. If you’re interested learning more about Agile, try here, here, here.
This is a question I get often and as it is a key element, and a designed limitation to the AbridgeMe platform, it certainly warrants an explanation. So here it goes…
When our team set out to develop AbridgeMe at the beginning of 2014, our vision was clear in wanting to create the ‘go-to’ resource for finding a quick, opinion-free, “elevator pitch” style summary on any topic.
Our own frustrations with the existing resources and their lack of concise explanations motivated us to develop and build a community where contributors were challenged to write concisely and learners were guaranteed to get up to speed quickly.
The keyword that continued to define our vision being, quick.
While quick is a somewhat subjective term and can take many forms, for us the definition was simple — we were looking for the convergence of two key elements:
What we found from a knowledge seeker standpoint (and this probably isn’t earth shattering news to anyone), was that the shorter the explanation provided to them, and therefore the quicker they were able to get up to speed on a topic, the better. They also noted that their time was an incredibly valuable resource and if we could free up more of it (by delivering concise explanations), they were 100% on board.
When presented two well-explained summaries on a given topic, they almost always preferred the shorter explanation.
Fact: 8 seconds = current human attention span
With knowledge seekers looking to get up to speed as quick as possible, this left much of the leg work to those delivering the content — the contributors. We saw some incredibly good writers that had the unique ability to explain both straightforward (think September 11th Attacks) and somewhat complex topics (think Arab Spring) very simply and get people up to speed in often times under 75 words.
For those writers who either did not have the skill of short, articulate, explanation or more importantly did not have a good understanding themselves on the topic being explained, their explanations tended to drag on and on (200+ words) — this was something knowledge seekers could not stand. Get. To. The. Point. They’d stress. A response that certainly falls in line with the 8 second attentions spans noted in the fact above.
The challenge of course also revolves around the complexity of the topic at hand. This is why we ultimately decided to broaden the length to 100 words — roughly 4 to 5 sentences on average. Take for example String Theory, an incredibly complex Physics concept that is certainly very difficult to explain in 100 words or less. What this does (and is a by-product we intended to create) is for these highly complex type topics, it really requires somebody with deep subject matter expertise to explain it in a concise, yet informative enough way for knowledge seekers to understand.
Our goal all along has been to attract the world’s leading experts in these more complex fields to contribute their simple explanations and help the world understand them…Neil deGrasse Tyson if you’re reading this please reach out, String Theory is all yours.
While we certainly wouldn't disagree that our 100 word constraint is a bit more of an art than a science, we do truly hope to make the world a more knowledgeable place by bringing together those with the ability to deliver concise explanations and the millions of people around the world looking to maximize their free time and get up to speed quickly on any topic.
This was a guest blog post on the was originally posted on Prsuit.com. You can find the post here
Similar to many entrepreneurs/aspiring entrepreneurs, I often dream up what I think is a “game changing” business idea.....Google it....then disappointingly find out that there are 10-plus variations of what I just thought of already in the market - many of which have taken my “genius” idea and gone even further with it than I could ever conceptualize. This falls in line with the phrase, “There’s an app for that!”, because more than likely there probably already is. Though, at the beginning of this year something different happened.
I was unassumingly searching online for a brief, unbiased explanation of a fairly complex topic to email to my girlfriend so she could better understand what I did at work – perhaps putting some context to my longer hours at the time. You see, I worked in Finance Technology, she was in Nursing, and explaining the complicated financial regulatory overhaul “Dodd-Frank” easily and effectively was becoming rather difficult. To my dismay regarding this ‘simple’ online task, I found nothing - all of the resources out there had their problems: biased content, lengthy articles, inaccurate information, advertising overload, etc. none had delivered a well-written, concise, fact-based explanation for anyone to easily comprehend (here’s the Wikipedia page for reference).
It was this lack of clear cut and concise explanations, and the hope to solve that problem, that ultimately led me to create the AbridgeME knowledge platform. My entire career leading up to this point revolved around solving complex problems and delivering technological and operational solutions. This problem however was a bit different (in a good way!), it was neither complex nor highly technical…the solution was simple, build a user generated content platform that the world’s professional and amateur writers alike can explain subjects related to their own expertise in always in 100 words or less. The constraint of 100 words fell in line with the famous Einstein quote “If you can’t explain it simply, you don’t understand it well enough” – which I believe is a key concept in learning and life in general.
While I really thought I had a great business idea on my hands, I needed to validate it with the general population (that would utilize AbridgeME to get up to speed on topics) as well as experts and writers that would contribute to the knowledge base of the platform. So what I did was quickly develop a basic landing website that explained the overall premise and had a way for visitors to sign up, send comments, and learn more about the to be developed platform. I also posted this simple infographic which provided a visual explanation of my goals with AbridgeME.
The feedback I got was highly positive; I was receiving comments and support from all around the world to build this type of resource. One piece of feedback, coming in all the way from Eastern Europe, really resonated with me as I had not even thought about how AbridgeME could be beneficial in this way:
“What a wonderful idea! AbridgeME will be especially helpful to people whom English is their 2nd or 3rd language!”
With the idea validated, it was time to bring AbridgeME to life. While I had a background in consulting and product development, I myself was not an expert programmer. My vision was to develop the crowdsourced website as well as a simple iOS app where users could quickly reference any explanations in the website’s database. I briefly shopped the concept of AbridgeME around to outside investors, but ultimately decided to fund the initial project myself and not waste time on the investor circuit. With myself leading the vision and product design, I was confident a contracted development team could bring AbridgeME to fruition.
With any side-project, especially one of this size, I knew this would mean late night and early morning working sessions to balance both my “real job” and developing the AbridgeME platform. This was a bit of a challenge at first, but I eventually changed around my routine (both at night and in the morning) to devote uninterrupted/focused time to the project – I believe this is key for anyone attempting to build a company while working a full-time job.
As we kicked off the development process, I also began actively reaching out to subject matter experts in various areas to get them to start helping build the initial knowledge base of AbridgeME. What I did not want to happen was to spend 6+ months developing a product, bring it to market, and there is no useful content available for users to take in. I got pretty bold and reached out to everyone from Steven Hawking (did speak with his protégé) to Neil Degrasse Tyson (no response :/). In the end, I was able to bring on some awesome writers from across the globe and am excited to say that we launched our open beta last month with over 500 topics summarized and ready to access. Most notably we had the world’s leading expert on Child Welfare at UPenn contribute her explanations on the Impact of the Sandusky Scandal and the current Child Migrant Crisis.
Within one week of our beta launch, we were covered by both Betalist and Erlibird – two of the most coveted technology early adopter websites. This was great in getting initial users to the platform to test and provide actionable feedback on the sites functionality and layout. Additionally, I had been in contact with my alma mater, Texas Tech University, and they wrote a great piece that explained my vision and goals with AbridgeME. The positive early press was another important validation and also helped greatly in driving both general site visitors and bringing on new contributing writers.
Where we stand now – just 1 month into the launch of AbridgeME.com - the AbridgeME story is still in its infancy. Other than continuing to actively develop our technology, our big challenge/push right now is reaching out to experts across the globe in various fields and getting them excited to contribute their knowledge to the platform.
I truly believe over time AbridgeME will become the household name for delivering quick, fact-based explanations on any topic. At the very least, I know the next person trying to explain Dodd-Frank to his girlfriend won’t have the original dilemma I had...
I have learned quite a bit in my professional career since graduating from college, but the last 6 months developing AbridgeME has taught me more about myself and my mindset to succeed than all of that time combined. Entrepreneurship requires a level of focus, ambition, and resourcefulness that a 9-5 job just does not bring to the table. I am excited as to what the future holds for AbridgeME, but am enjoying every step of the journey as I know each hiccup and road block I encounter is just part of growing into a successful Entrepreneur.