 When building a technology product - whether you're creating an application from scratch, or evolving an existing platform - it's paramount to have clear goals set, and ways to measure those goals throughout the entire product journey. In my experience, without those well-defined goals it’s far too easy to fall into the trap of “shipping product” as a measure of success. “We launched 10 new features this quarter. High five!” Shipping product is an output, not an outcome. If you focus too much on outputs, such as how many features your team shipped in a given quarter, the customer's needs can start to take a backseat. I've seen this scenario play out across several organizations, perhaps you have too... The Product Manager wants to make sure that their scrum/development team stays busy or else they fear that they'll lose those precious resources to other teams. So, they keep adding and adding to the product backlog and continue launching new features without an outcome in mind to measure success. The result, "feature bloat"...think the clutter of the (old and probably current) Yahoo homepage. On the flip side, think about the clean nature of Google's homepage. That's because Google has always focused on the outcome of "delivering the best search results" to their customers. Outcomes directly align with what a customer wants and allow the product leaders (Product Managers, Entrepreneurs, etc.) to operate in a more customer-centric manner (this is how the great Product-led companies run, think Amazon/Google). Outcomes are what also motivate a team to really empathize with the customer and take ownership of their problem <- this is where the magic happens. Remember, “Customers don’t want a quarter-inch drill. They want a quarter-inch hole“ - Theodore Levitt Quarter-inch drill = Output Quarter-inch hole = Outcome Now before we get into how OKR's can help us build better products through focusing on outcomes, let's level set by looking at the two things I believe technology products need to do really well:
 This simple test stands true across the spectrum - from non-profits to multi-national corporations. Even non-profits that launch technology tools need to ensure that they are in tune with the larger organizational goals. If not, you'll have a massive disconnect and precious dollars will be sent down the drain. [OKR’s have entered the chat] OKR’s are a great goal setting framework because they marry a qualitative vision with measurable ways to determine success. They help us product builders manage outcomes and ultimately build world-class products. On a personal level, the OKR framework has been extremely helpful to me over the last three+ years running a technology startup where we were one of the first entrants in the space. Because the technology itself was so new, conversational AI, the end users (customers) didn't always know what it is they wanted from it + we didn't know what would stick and truly solve a problem for them. So, we ran a ton of experiments - but, we always made sure we had an outcome in mind when doing so. By having clear outcomes set, it made it easy to cut those products/features that weren't meeting them - and equally important, double down on those that were. OKR's also helped make sure that we were aligning with the larger company vision (showcased in the diagram below).  So what are OKR’s O = Objectives — “what” it is you are trying to achieve. Simply, the goal. KR = Key Results — “how” the objective (goal) can be achieved. Also a measuring stick. They follow this formula: OKR = 1 Objective + 3x Key Results (note: the # of key results varies by preference, I like to go for 3) How often do you define OKR’s For product-focused OKR's I stick to quarterly — this keeps them more tactical and focused. From my personal experience, products evolve rapidly and often. Company-wide OKR’s are often better suited for annual, but it’s ok to also include some annual OKR’s that are product focused. Writing great objectives When writing an objective, make sure that it meets the following requirements: • It’s bold and aspirational • It’s specific • It's in alignment with organizational goals • It's measurable Writing great key results Key results serve as the steps needed in order to successfully reach an OKR objective. Effectively, if you meet your key results you’ll have then met your overall objective. An analogy that I think paints the picture nicely of what key results are is that they serve as a 'GPS' that helps you navigate towards your goal (objective). Key results should follow the SMART method (Specific, Measurable, Actionable, Relevant, Time-bound). Let's write an OKR together But first, let's start by what NOT to do. Here's an example of a poorly written product OKR (then we’ll optimize it)... O: Improve traffic to our website in Q2 2019 KR 1: Have team write more articles KR 2: Add new ways for chatbot users to access articles KR 3: Analyze traffic to website and think of ways to optimize Off the bat it's obvious that the objective (goal) itself is vague... What are we comparing the improvement to? Are we talking about unique users? Total page views? The key results are equally as vague. These are not measurable or actionable. Now, let's improve it... O: Drive 500k unique visitors to themindfultechlifestyle.com in Q2 2019 KR 1: Publish 2 articles per week during Q2 KR 2: Increase call to action buttons within all live chatbots by 25% in Q2 KR 3: Reduce website load-time by 50% as measured with GTMetrix The objective itself is now clear and measurable. Our goal was to reach 500,000 unique users during Q2 2019 (April - June). The key results here are equally as detailed and actionable as you can see. These can now individually serve as our GPS as we navigate towards our goal. 5 Real world OKR's from my company Below, I've shared a bunch of actual OKR's from my last company to help you frame out your own, enjoy... O: Increase profitability by 15% in Q3 2019 KR 1: Optimize display advertising through Google Adsense to only show ads with a cost per click greater than $.50 KR 2: Decrease 3rd party platform expenses by 25% KR 3: Increase daily article broadcasts by 20% O: Decrease the number of default responses sent to chatbot users by 25% KR 1: Use Yandex reporting tools to create a weekly report of utterances not understood by all chatbots and have them sent via email to team KR 2: Divide report equally across team to conduct a weekly review of report KR 3: Formulate and launch responses for at least 75% of utterances not understood O: Increase button click through rate (CTR) by 25% across all chatbots by the end of Q4 2019 KR 1: Change all text in call to action buttons to use active language KR 2: A/B test call to action buttons for each daily broadcast to identify the best results and implement KR 3: Hire an expert copywriter to refine and optimize all buttons by November 1 O: Launch versions of 3 chatbots on voice channels in Q1 2019 KR 1: Hire a developer with experience on Alexa by Jan 15 KR 2: Create a simple version of MeditateBot, MotivateBot, and StoicBot on Amazon Alexa KR 3: Cross promote to new channel via call to action buttons in persistent menu of related chatbots on Messenger O: Get 50 positive testimonials and showcase them on company website in Q4 2018 KR 1: Setup designated email address to receive and review testimonials from users KR 2: Encourage chatbot user base to send short reviews of their experience to success@themindfultechlab.com with call to action buttons in daily broadcasts in Q4 KR 3: Create a page called “Impact” on company and include the best 50 testimonials Eric Rems ericrems.com  Update: As of May 2020, MeditateBot has reached and helped over 1.5 million people around the world. Over the past few years, Facebook Messenger has become the go to place for over a billion people worldwide to engage in their daily conversations. Though over the past year, it’s also quickly become the place where these same people are getting their daily news, weather updates, booking travel, style advice and much more. This phenomenon began back in April 2016 when Facebook opened up their API for developers to create chatbots — programs to simulate human conversation. The rise of chatbots are giving brands an entirely new way to communicate with their audience at scale, a way that is so innately human…through conversation. New Habits are Hard When launching a new technology product, one of the biggest challenges is getting people to use it daily. New apps struggle with this often. Think about all of the times you’ve downloaded an app, used it once or twice, then deleted it or never opened it again. It’s hard to create that stickiness that keeps people coming back. This same issue product makers face with getting people to use their apps daily, we all face in our lives with trying to create a new positive habit. Want to start working out? Ok, you go to the gym three days straight, then something comes up and you can’t make it, then again you miss it. A few weeks later the thought of going to the gym is so far in the back of your mind it never resurfaces. In my opinion, the key to forming and sustaining any new habit is two fold:
An Idea As I thought through this with one of my own habit struggles, meditating daily, I decided to test the forming of a new habit by leveraging the power of Facebook Messenger — a place which already had my eyeballs as it was quickly becoming part of my morning routine for news, weather, etc. The end result of a weekend personal hack-a-thon was MeditateBot — a Messenger chatbot that teaches the benefits of meditation, surfaces a variety of meditations, and even lets you schedule a daily reminder — all for free within Facebook Messenger. I’m extremely happy to say that after 4 weeks since launch I have successfully meditated daily using MeditateBot. And more importantly, so have over 25,000 other people :) Here’s how I made it habit forming enough for me keep it up a daily practice for 4 weeks and counting… Schedule a Daily Reminder  This feature is the linchpin to the entire experience. By asking what time works best for people and sending them a reminder daily at that time, they are empowered to make meditation work for their schedule. At the scheduled time, a simple push notification is sent that gently nudges them to kick off their daily meditation. I personally check Messenger in the morning while I’m eating my breakfast, so I schedule my daily practice reminder at 8:00am every day. It fits nicely into my routine and I know I’m not distracted at that time. Analyzing the data of scheduling on MeditateBot, it was insightful to see that user’s reminders were almost perfectly distributed across all times throughout the day — morning, afternoon, and evening. This proves that everyone has their own “best” time. Make it work for you! Showcasing the Benefits  Some people needed a little backing as to why daily meditation would be good for them, especially those that may have just stumbled across MeditateBot after it was featured in Messenger (grateful for that!)  Succinctly explaining the benefits of meditation, then having a CTA (call to action) immediately after to meditate has resulted in a >70% conversion to completing a meditation. Priming with benefits is important for driving action. Having Options, But Not Too Many  Too many options is too much, make it simple and don’t let the mind wander when the attention is already there. I’ve seen too many apps that have an endless amounts of options, this makes it hard to select the “right” one — which causes frustration (not a good primer for meditation!). For MeditateBot I’ve kept the categories high level and made sure all speak for themselves. No explanation required for the three types:
Time Variations  Another important option in building a new habit is to not bite off more than you can chew. If you’re forcing yourself to do a 20 minute meditation daily out the gate, you will get frustrated.
Why is my mind wandering? Is it over yet? Am I doing this right? Having the option to choose a length that your willing to devote, keeps the barrier to entry low. Even getting 1 minute of that meditative state is shown to bring a heap of benefits. Eric  “Tell me about your side project, what’s that about?”
That’s how my interview began a few years ago, and ultimately ended — talking about the side project I had been working on for the past year. We discussed how I came up with the idea, developed the initial requirements, designed product mock ups, hired an overseas development team, launched the product, iterated the product, and pitched investors…while holding down a full-time job working on Wall Street. They loved it, even though in my mind it couldn’t have been any further from the position I was interviewing for — digital media (my project) and institutional finance normally don’t overlap. Prior to my interview, I had heard that the firm was known as having one of the most difficult hiring practices in the industry. This led me to later question how I stood out among other candidates once I got the call that I had been hired to be a Product Lead developing technology solutions for the world’s capital market leaders. I’ve spoke with several recruiters and hiring managers after landing that job and pulled together 5 reasons why side projects help candidates stand out. 1. Proves You Are a Self-starter Everyone has ideas, few people execute them. Nothing says you are a self-starter like taking an abstract concept and bringing it to life. As you climb the career ladder and take on more responsibility, you have fewer people above you telling you what to do. Being a self-starter proves to employers that you won’t just sit around and wait to be told what to do — you’ll run with your ideas. 2. Showcases Your Toolkit Launching a side project often means you’re taking on the role of idea generator, maker, marketer, designer, etc. In the cross-functional world of modern employment, employers love your ability to interact with other areas of the business and often even taking on roles that may be “outside” of your defined position. At no point during my full-time career had I ever pitched journalists. Identifying relevant journalists, cold pitching them, and ultimately getting press coverage was something I would have never done in my day job. 3. Displays Your Appetite to Learn One of my most recent side projects, a Google Chrome extension called New Tab Motivation, was simply a way for me to understand JavaScript (a language frequently used in development, but I knew little about). What better way than learning the basics of a language than actually building a product, albeit an extremely simple one. 4. Shows Off Your Time Management Skills Nothing says time management skills like holding down a full-time job and launching a project on the side. Being based in NYC, and hiring a development team in India (12 hr time difference) to get AbridgeMe off the ground, my team was literally working on my side project while I was sleeping. When I’d get up early in the morning they were wrapping up their day and I’d review their work, chat over Skype about what they accomplished, and discuss what they should work on the following day. 5. Demonstrates Your Creativity We’ve all heard the overused cliche “think outside the box”. Bosses have been saying this for years to employees, but have probably never meant it more than in today’s environment. Every industry has either been disrupted or is in the process of being disrupted and business leaders want creative thinkers. Launching a side project proves you don’t like seeing things the way they are and instead want to build something different. With one of my newest side projects, MotivateBot, I wanted to explore building a Facebook chatbot. I also had been looking for a way to start my day on a more positive note. Combining both of these goals, I created MotivateBot in Facebook Messenger to deliver motivational quotes every morning to kick off each day with a bit of inspiration. Looking back at my life post-college (about 10 years), I’ve worked on a series of projects with varying levels of success. At no point while creating and growing these ideas did I ever stop to think, “this project is really going to help me land a job in the future.” I was genuinely just interested in doing things outside of my day job remit and pursued them — I suggest you do the same if you’re curious about any area outside of your day job. Eric  Being stuck behind a computer for the better part of the day my mind tends to effortlessly navigate from one thought to the next, guiding me to tackle many different tasks at a time, and in turn forcing me to open up a new browser tab about once every few minutes. Most of the time I don’t even realize how much I’m “multi-tasking” until the text that normally appears on the browser tab is no longer even displayed, thus causing an extremely hard time to navigate between each — something I refer to as “Tab Roulette” (pictured above). Why so many browser tabs? Science explains. As someone interested in the human condition as a whole, as well as my own self-growth, I started looking for an answer to this multi-tasking behavior. Many, many browser tabs opened later, research showed that we as humans are biologically programmed to be rewarded each time we complete tasks (no matter how simple they really are). What is actually happening there is that each time we complete a task, our brain gets a “hit” of dopamine (the pleasure chemical). We love dopamine, which makes it addictive to get rewarded for even the most menial tasks. Checking email → Dopamine Booking dinner reservations → Dopamine Responding to a chat message → Dopamine But I have bigger goals. Understanding the science of why I’d multi-task, it was obvious that throughout my day I’d get so caught up in the wormhole of completing tasks that I’d often forget to step back and think of the big picture. This was frustrating to me because I had much bigger goals than these small tasks, but they often seemed to slip my mind — something like a “motivation blackout”. Maybe even worse than not being reminded of these goals was the fact that I’d feel drained (a side-effect of multi-tasking) by the end of the day and lack the motivation to work towards them. As someone looking to be a high performer at work and on my own projects, I needed to find a way to keep my motivation level high even when I’m stuck in the task wormhole that often comes with the 9–5. Don’t argue with Science, hack it. Knowing that my body was likely not to change in the near term, I instead decided to hack the process and inject a subtle hint of motivation into my day to day. What I’d often find myself doing when I lacked motivation was searching for inspiring quotes by known leaders, something that is apparently common practice. The problem was, doing this required me to be proactive and realize that I was running low on motivation, something that I often overlooked. So by putting some of my (basic) coding skills to work, I built an incredibly simple Google Chrome Extension that delivers a motivational quote each time I open a new tab and appropriately called it New Tab Motivation.  So now, whenever I’m attempting to complete various tasks, I’m delivered a low-touch jolt of motivation in my browser. This boost didn’t require me to download an app, pull out my phone and check Instagram for a motivational post, or even search for inspiring quotes to get me through the day, but instead was right there seamlessly into my daily routine.
In developing technology products over the years, one of the major themes I’ve realized is that creating an entirely new behavior for people is incredibly hard to do. Instead, building something that is already part of a routine (i.e. opening browser tabs) is the best way to engage and create a useful tool that people will actually use daily. If you’re a Google Chrome user that wants to get that extra boost of motivation throughout the day then check out New Tab Motivation.  Whether you’re a seasoned Software Engineer, bright-eyed Product Manager, or have never even heard of the term Agile Software Development, you too can live a more productive and happy life by leveraging some of the same Agile principles that are used to build most of the software products we use today (think Twitter, Facebook, Snapchat, Uber).
By just quickly looking at a few of the basic tenants that Agile software development promotes, it is easy to see that it resembles much of what the self-improvement gurus of today preach: Simplicity, adaptive planning, reflection, continuous improvement, regular adaptation to changing circumstance, face-to-face conversation I spend my day building tangible products for a wide range of users, but it’s the time I spend away from my work where I continue to build the most important product of all — my personal life. Without actively meaning to over the past few years, I’ve managed to adopt many of the same Agile principles I use to build software products to now live a better life. I hope you benefit from at least one (if not all) of these simple to adopt concepts… Product Backlog In Software Development: The product backlog is considered the “playbook”, or master to-do list, of all the features for the product you plan to build. Without the product backlog, you have just an idea for a product, but no actionable list of what needs to be delivered by the development team (I wrote more on this concept here). Since the product backlog is used by developers to turn the idea into actual code, and ultimately a tangible product, specificity is key. You can’t just say “Press a button and users can order food”…this would leave thousands of open questions from the developers. Generally, the most important features appear at the top of the product backlog so the team knows what to deliver first, though items are often refined and re-prioritized over time — this is referred to as “backlog grooming”. In Life: We all have a running to-do list of what we’d like to accomplish in the next hour, day, month, year, etc. (from “sending rent” this afternoon to “get a new job” sometime in the future…), but often lacking detail and prioritization of what needs to be done. How many times have you said you want to get a new job? Or start working out at the gym? These are two common examples of vague and weak tasks/goals. Just as software developers can’t execute poorly described features, you too can’t action on these vague requirements. Put your to-do list in an actionable state and the results will come.
Sprints In Software Development: Here is where the prioritization of the backlog comes into play. Since your development team is limited by both time and # of developers (we call this capacity), it is important to deliver the most desired, and value added features first. In software development we refer to these as “sprints” — normally two to four week periods of time where a development team tackles a series of features from the product backlog. In Life: This is simply taking items from the highest priority on your ever-growing to-do list and actually completing them. Our “sprints” in life often come in the form of weekends because there tends to be little time during the week to tackle to-do list items. There will always be some low hanging fruit (i.e. take out trash, wash clothes, etc.), but be sure to mix in some of the more larger and difficult items (i.e. refine my resume, look for a new apt) during your sprint. Stand-Ups In Software Development: Stand-up meetings are daily, time-boxed (normally 15 minutes), meetings that take place during a sprint. The concise nature of this meeting ensures fast, but relevant discussion between team members. During the daily stand-up, each team member answers the following three questions:
In Life: Ask yourself these very same questions every morning to keep you honest. You’re probably familiar with this Steve Jobs quote: “I have looked in the mirror every morning and asked myself: If today were the last day of my life, would I want to do what I am about to do today?” And whenever the answer has been “No” for too many days in a row, I know I need to change something.” These simple questions will help you verbalize (or in your head; on paper/in phone) your daily activities and help you draw in on how you are actually spending these finite days on Earth.
Retrospectives In Software Development: Retrospectives are meetings that take place at the end of a sprint (defined period of work) where the team all sits together to talk about what’s working, what isn’t, what opportunities people are seeing, and which challenges they are facing. It’s about constantly checking in and questioning whether the team’s approach is still making sense given everything new it learned. On my products, we use the terms ‘Highlights’ and ‘Lowlights’ to list out what we thought to be the good and bad of the last iteration. In Life: Unlike the daily check ins (stand-ups), the retrospective can be more thought of as a longer term review (think weeks or months) of what is working and what isn’t in your life. If you have a significant other it’s great to include them in your “retro” — these conversations can range from your job to living situation to travel to really anything. A simple way to approach this is take each major category of your life — 1. Career 2. Dating (or Marriage) 3. Health, etc. then talk or list out your ‘Highlights’ and ‘Lowlights’ of each. Career Highlights
Utilize tools where needed In Software: It’s virtually impossible to build complex software without leveraging tools such as Jira, Rally, Trello, etc. These tools allow you to collaborate, organize and effectively track progressive during the development process. In Life: Life is complex…even more complex than code. So why are you keeping everything you need to do, want to do, have done, in your head (or even a running list in Apple Notes)? I use the free application Trello (both the web and iOS app versions), which is also often used in software development. I’ve been using Trello as my personal to-do list for a while now, and most recently my fiancee and I have started using it to plan our wedding. Trello makes it easy to create actionable to-do list items and move them to the ‘done’ folder once completed. Not only does this help you track your progress, but also gives you a nice jolt of joy when you drag and drop from ‘To-Do’ into ‘Done’. These are just a few examples of how you can leverage Agile, a technique widely used in the software development community which took an extremely complex subject (software) and simplified/improved upon it, to improve various aspects of your life. Eric  Note: The inspiration for this post came from the book Buddha’s Brain — highly recommend if you’re interested in neuroscience. I am by no means an expert in this space and just enjoy learning and sharing thoughts about the brain and how it controls our actions/thoughts. Take all of this with a large grain of salt.
We’ve all been there before…sitting at the airport…patiently waiting at the gate for our flight to board…excited to kick off our “much needed” vacation…then the announcement… “This flight has been DELAYED” Of course, just as soon as you hear the word “Delayed” a series of negative reactions ensue: I told her to book the earlier flight, why did she not listen and book this one! This always happens to me! Who is responsible for this!? There goes my vacation! [sound familiar?] These reactions are referred to as Second Darts. Second darts most often serve no real purpose and disproportionately harm us compared to the inevitable first darts. Simply, they are a result of the mind reacting negatively to the experience. When first darts don’t even exist One of the saddest parts of all is that many first darts don’t even exist — they are entirely drummed up in our mind. Have you ever thought about the scenario of your boss calling you into their office to tell you that you’ve been laid off. Perhaps you’ve been called out in meetings the past few weeks and are feeling less than comfortable about your work product. On top of that, you’ve heard rumors circulating around the office that layoffs are coming soon! So what do you do??? Naturally, you fire off a first dart → I’m going to get laid off. Then, the second darts ensue…. How am I going to pay for my son’s school!? We are going to have to move in with my parents because I can’t afford our mortgage! The market is terrible, how the heck am I going to find a job!? My wife is going to think I’m a failure! Wait. Wait. Wait. You are now thinking about moving in with your parents (which is more than likely depressing you and affecting your current mood) based of an entirely hypothetical situation — getting laid off. Doesn’t this seem crazy? Negative reactions to positive events Sometimes we actually react negatively to situations that are inherently positive in nature. Think about a time whenever something that was supposed to be great for you actually resulted in you thinking about it in a negative light. So your boss just offered you a great opportunity at work to step up and take on a bigger role → you can’t stop thinking about whether or not you’ll fail and disappoint (second dart)… What if I look dumb in a meeting with Executives? I’m not supposed to be in charge of something this important? Am I even smart enough to do this? So what’s happening in the brain It is extremely important to realize that even just thinking about a first dart kicks off a series of effects on the body. To paint the picture a bit more, here is the chain of events that occur once a first dart is set off in the untrained mind. First Dart: Getting laid off from work…
How to avoid second darts The good thing about all of this is that with a little bit of self-awareness and positive filtering of your thoughts, you can save your body and mind from the negative physiological and psychological impacts. Here are a few ways:
“There is only one way to happiness,” Epictetus taught the Romans, “and that is to cease worrying about things which are beyond the power of our will.” ― Dale Carnegie, How to Stop Worrying and Start Living  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. Congrats. 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:
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). 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. |
AuthorSharing my perspective on product building and a little bit on life. Archives
November 2020
Categories |
RSS Feed