tag:product.adamwiggins.com,2014:/feedAdam Wiggins2013-11-25T14:51:25-08:00Adam Wigginshttp://product.adamwiggins.coma@adamwiggins.comSvbtle.comtag:product.adamwiggins.com,2014:Post/the-product-feature-lifecycle2013-11-25T14:51:25-08:002013-11-25T14:51:25-08:00The Product & Feature Lifecycle<p>Product development is a lifecycle. It starts when we have our first hunch about a new product, and spans all the way to the day when that product is decommissioned after a long and successful run.</p>
<p>Here’s my framework for the lifecycle of a product or feature, in five phases.</p>
<h2 id="phase-1-research_2">Phase 1: Research <a class="head_anchor" href="#phase-1-research_2">#</a>
</h2>
<p>Anyone who works in product development (engineers, designers, product managers, and product-focused entrepreneurs) are passionate about building things. So our inclination is to jump straight to building a solution. But without doing our homework, we don’t have all the information, the context, the knowledge we need to build the right thing. Going directly to building something will almost certainly result in a huge amount of wasted effort.</p>
<p>In research we ask fundamental questions like: who is the user? What problem(s) do they have that we think we can solve? What are they doing today to solve this problem? How do they think about the world?</p>
<p>We don’t ask these questions abstractly or answer them with speculation. Instead, we follow our hunches out into the world and find the type of people we hope to serve, talk to some of them, and try to gain understanding about them and their needs.</p>
<h2 id="phase-2-discovery_2">Phase 2: Discovery <a class="head_anchor" href="#phase-2-discovery_2">#</a>
</h2>
<p>Informed about our target users and the problem we believe we can solve for them, now we get to what most of us consider the fun part: product discovery.</p>
<p>In this phase, we’ll get to generate ideas by the bucketload, and make them concrete through techniques like wireframing. We’ll create many variations on our ideas and sort through them to find the most promising ones.</p>
<p>We design and build very rough versions of these ideas, called <a href="http://product.adamwiggins.com/the-basics-of-prototyping">prototypes</a>. We put these prototypes in front of our target users, a process called user testing. This process of prototyping and testing happens extremely quickly: a few days per prototype and user test. Not months, and certainly not years.</p>
<p>While testing with users we ask questions like: Can they understand it? Are they able to use it? Does it get them excited as a potential solution to their problem? Can they see it being a part of their daily life? Would they pay for a finished version?</p>
<p>Most of the time, the answers to these questions will be no, and we’ll go back to the drawing board more enlightened about the problem space and the needs of our users.</p>
<p>After many experiments, we hope to find some prototypes which give us a resounding “yes” to the questions above, something called product validation. This is one of the most exciting moments in product work, and sets us up to enter the third phase.</p>
<h2 id="phase-3-delivery_2">Phase 3: Delivery <a class="head_anchor" href="#phase-3-delivery_2">#</a>
</h2>
<p>Most product teams skip the first two phases and start work on new products and features here. Skipping ahead is one reason that so many products fall flat in the marketplace. No one cares about the product, because the creators of the product didn’t take the time to care about users and what they need.</p>
<p>But we’re taking a different approach: having done research and discovery, we can begin building the final product with confidence that we’re pursuing a product opportunity that creates real value for real people.</p>
<p>The delivery phase is primarily focused on engineering a scalable, finished version of the product. We probably have a working prototype created during discovery, but <a href="http://product.adamwiggins.com/prototypes-are-disposable">prototypes are disposable</a>, so during delivery we engineer a finished product which will scale out to the number of users we expect once we launch.</p>
<p>Delivery also includes figuring out how to explain the product: through documentation, marketing materials, or helping the sales team understand the benefits of the new product. There’s also many logistics for how the product gets into the user’s hands, from rollout (for pure software products) to manufacturing, packaging, and fulfillment (for physical products).</p>
<p>When delivery is done, our product is launched and in the hands of its intended users. Now we let the marketing and sales teams do their jobs to spread the word and get many people to try, use, and buy.</p>
<h2 id="phase-4-operation_2">Phase 4: Operation <a class="head_anchor" href="#phase-4-operation_2">#</a>
</h2>
<p>This is the longest, most labor-intensive, and most important part of the product or feature’s life. Your salespeople are selling it, users are using it, engineers are fixing bugs, support staff is answering questions. All the non-product development functions in the company now take control and make the most of the product or feature’s existence.</p>
<p>The product lifecycle is fractal: you may have launched a new product, but your work as a product person is far from done. Now you’ll be applying this lifecycle to individual features on the product, trying to incrementally increase its value to existing users or help it serve the needs of new users who are adjacent to your existing market.</p>
<h2 id="phase-5-sunsetting_2">Phase 5: Sunsetting <a class="head_anchor" href="#phase-5-sunsetting_2">#</a>
</h2>
<p>A successful product may be in operation for years or even decades. The telegram, one of the most successful technology products of all time, <a href="http://www.nbcnews.com/id/11147506/#.UoAUN5Sbg0M">lasted over a century</a>. An unsuccessful product may operate for only a few months. But sooner or later, all products reach the end of their lives.</p>
<p>Sunsetting is the process of gracefully phasing out the product. If we execute well, the remaining users of the product or feature will feel respected and cared for. We’ll help those users find a suitable replacement (usually a newer version of the product) and transition them to that replacement with a minimum of hassle and cost.</p>
<h2 id="why-this-matters_2">Why this matters <a class="head_anchor" href="#why-this-matters_2">#</a>
</h2>
<p>Clarity about where a feature sits on this timeline can make a huge difference in our ability to talk about it with our colleagues on the product development team, with other people in the company, with our users, and with investors.</p>
<p>For example: a feature which is in the second phase, discovery, is not yet ready to sell. In fact, it may never ship at all. If you’re a salesperson, you’re setting everyone up for disappointment if you promise the customer a discovery-phase feature, especially if that promise was key to closing the sale.</p>
<p>If you’re an engineer considering refactoring a block of code, knowing if that code is associated with an operation-phase feature (or not) will help you make better decisions about how to handle that code, from test coverage to security audits.</p>
<p>If you’re a potential investor in a company, knowing the difference between a product which is a prototype still in discovery versus a fully validated product in operation may help you make better investing decisions. Most startups are in discovery for their entire product for their first year or more.</p>
<p>Perhaps most importantly, having a shared vocabulary about the product lifecycle will help us answer one of the most common questions: “When will this (product or feature) ship?” The answer is always: when we’re done with delivery. If the product or feature still in research or discovery, the answer is: “Impossible to know; and it might never ship.” If it’s in delivery, we can offer an accurate timeline and make plans for marketing, manufacturing, customer service, and other operational needs for the finished product.</p>
<h2 id="conclusion_2">Conclusion <a class="head_anchor" href="#conclusion_2">#</a>
</h2>
<p>I view the lifecycle of products and features as a timeline with five phases: research, discovery, delivery, operation, and sunsetting. Having a shared understanding and set of terms around this process can help a product development team and the entire product company operate more smoothly.</p>
tag:product.adamwiggins.com,2014:Post/prototypes-are-disposable2013-11-18T11:11:08-08:002013-11-18T11:11:08-08:00Prototypes Are Disposable<p>During product discovery, we create <a href="http://product.adamwiggins.com/the-basics-of-prototyping">prototypes to answer questions</a>. Questions like: what size should the product be to fit nicely into our target user’s grip? Should our shopping cart software split the checkout process into multiple pages? Would our users find value in a version of our app ported to Android tablets?</p>
<p>Since the goal is to answer questions, we build prototypes as quickly and cheaply as possible. A prototype is not a carefully-engineered artifact, meant to stand the test of time. Instead, prototypes are disposable, to be thrown away once their purpose has been fulfilled.</p>
<h2 id="throw-away-failures-and-successes_2">Throw away failures and successes <a class="head_anchor" href="#throw-away-failures-and-successes_2">#</a>
</h2>
<p>A completed prototype might be considered a failure (or “falsified”) for any number of reasons. The designer may feel that the design is not sufficiently useable and doesn’t see any obvious tweaks to improve it. The engineer got it working using metaphorical duct tape and bailing wire, but doesn’t see a technical approach workable over the long term. Or, most commonly, a user test reveals that users can’t understand the prototype, or shrug their shoulders when asked whether they would use it or buy it.</p>
<p>All of these cases mean our prototype has reached a dead end. Such falsified prototypes are discarded, and we go back to the drawing board with more understanding of the problem space, the technology, and our users’ needs.</p>
<p>But less obvious is why we discard successful prototypes. (By “successful” I mean “validated,” a topic for a future post.) Here’s why even successful prototypes are disposable.</p>
<p>The successful prototype, like all our other prototypes, was built fast and cheap. It was never engineered for use on a large scale. If it’s a mobile app prototype, it was probably made only to work on one phone device, screen size, an OS version. If it’s a web app prototype, it probably hasn’t had any attention given to database performance, security, or test coverage. If it’s a physical product, the prototype may be 3D printed but the finished product needs to be mass-produced via injection molding.</p>
<p>The destiny for a validated prototype is to become a template, a working specification used to build the finished product. (I’ll explain this part of the process in a future post.)</p>
<p>Once we cut free of the expectation that a prototype should be engineered like a finished product, we have far more freedom and speed during the prototyping process. Being able to build faster and cheaper means testing more ideas, which means a better end product.</p>
<h2 id="realworld-example-tetryon_2">Real-world example: Tetryon <a class="head_anchor" href="#realworld-example-tetryon_2">#</a>
</h2>
<p><a href="https://itunes.apple.com/us/app/tetryon/id532398542">Tetryon</a> is an iPhone game created by Miranda Collins and me in 2009. Our goal was to create a simple but challenging puzzle/strategy game inspired by classic board games like Go and Chess, and video games like Tetris and Klax.</p>
<p>One early prototype we created was intended to answer the question: how big do the game pieces need to be in order to make them easy and fun to “grab” with your finger? Bigger would make them easier to grab, but smaller would allow for more pieces onscreen and therefore more interesting gameplay.</p>
<p>We created a tiny prototype using a playfield of a grid of lines, and a sprite borrowed from another game as a game piece. I got the prototype running on my phone and we were able to try the sprite at different sizes to see which one felt best.</p>
<p>This disposable prototype did need to be real enough to run on the target device, but it didn’t need to look good, have game mechanics, or do anything other than let you drag around the game piece. It didn’t even need to run on anyone’s phone other than mine. This was a fast, cheap way we could answer the question about game piece size, and required only a few hours of work.</p>
<p>We spent months and hundreds of iterations on another disposable prototype designed to answer a different set of quetsions. Written in Python, this prototype ran on a desktop computer with a game window exactly the size of the iPhone screen. Python is a higher-level programming language, and one I was more familiar with. This allowed us to iterate on ideas much faster than the iOS’s native language, Objective C.</p>
<p><a href="https://svbtleusercontent.com/pqran82zvihr6g.png"><img src="https://svbtleusercontent.com/pqran82zvihr6g_small.png" alt="tetryon-protoype-and-finished-product.png"></a></p>
<p><em>(left) Early prototype written in Python running on a desktop computer. (right) The finished game running on an iPhone.</em></p>
<p>We used the Python prototype to explore the art style, build out the game mechanics, and have our friends playtest the game. We answered questions like: Which of our ideas for game mechanics are the most fun? Can users figure out the mechanics via trial and error, or should we spell everything out in the tutorials? How quickly should the difficulty level ramp up on early levels to keep players engaged, and not bored or frustrated? These questions required a high-fidelity prototype, but it did not require that it run on our target device.</p>
<p>Once we had locked in most of the gameplay and art with the prototype, we transitioned out of product discovery and into building the finished product. We used the Python prototype as working specification to create a brand new codebase in Objective C on the iOS platform. This from-scratch rewrite took about two weeks, and afterward we discarded the Python codebase.</p>
<h2 id="prototypes-are-not-products_2">Prototypes are not products <a class="head_anchor" href="#prototypes-are-not-products_2">#</a>
</h2>
<p>In software, late-stage prototypes often look very real. This is great for testing our hypotheses, but it creates a pitfall: our product development team and other stakeholders can mistake a prototype for a finished product. “Great,” says the boss, seeing a demo of your high-fidelity, fully-functional prototype operating against production data. “Let’s ship it next week!”</p>
<p>No matter how real it looks, the prototype exists to answer a question. It was never intended for, or engineered for, wide use. For a company with a large existing userbase, trying to launch a prototype usually results in public failure. The engineering team will be forced to rebuild the prototype as a production-ready product under unreasonable time pressure, and the customer service team will be forced into damage control.</p>
<p>Brand-new startups can launch prototypes as if they were finished products, because they have no existing users. Even in this case, though, I recommend using a method for metering incoming users, such as invite-only private alpha, or a signup / waiting list beta.</p>
<h2 id="conclusion_2">Conclusion <a class="head_anchor" href="#conclusion_2">#</a>
</h2>
<p>Let go of the expectation that prototypes need to be designed and engineered at the level of a finished product. It will allow your team to iterate more quickly toward finding a truly great product opportunity. Build each prototype fast and cheap, and plan to throw it away when its purpose has been fulfilled.</p>
tag:product.adamwiggins.com,2014:Post/the-basics-of-prototyping2013-11-11T12:21:25-08:002013-11-11T12:21:25-08:00The Basics of Prototyping<p>In product discovery, our goal is to test many ideas with real users. The faster we test each idea, the more ideas we test. And the more ideas we test, the better our chances of discovering a great product opportunity.</p>
<p><a href="http://www.svpg.com/dual-track-scrum/">Building and launching a finished product is the slowest, most expensive way to test an idea</a>. So instead, we’ll use a technique known as prototyping, which lets us quickly and cheaply make our ideas real, and allow us to test those ideas with users.</p>
<h2 id="what-is-prototyping_2">What is prototyping? <a class="head_anchor" href="#what-is-prototyping_2">#</a>
</h2>
<p>A <em>prototype</em> is a rough approximation of what a finished product could be. <em>Prototyping</em> is the process of creating that approximation.</p>
<p>If you’ve ever hung a picture on your wall, you’ve made a prototype. “How does this look?” you asked, holding up the picture. “A little to the left,” your spouse or roommate says. This is a prototype: it looks very similar to the end product, but you try out variations quickly and easily — without hammering a bunch of nails into your wall. But the prototype is not the end goal, since you cannot stand there forever holding the picture. So once you find the right spot, you drive in a nail and hang the picture on it: and that’s your finished product.</p>
<p>Prototyping is an immensely powerful technique. It helps us gather our thoughts. It helps us compare options. It helps us have a healthy debate on our product development team. It helps us get buy-in from stakeholders. And it’s how we test and thus validate or falsify our product hypotheses with users, without needing to invest in the cost of building a finished product.</p>
<p>While creating potential product designs, we often use <em>wireframes</em>. Wireframes are a sketch of how the product might look, and a central technique in the brainstorming and design process. Prototypes differ from wireframes in that they are interactive. A prototype is something that we, and our users, can try out.</p>
<p>There are many approaches and tools for creating prototypes, including clickable wireframes (software), 3D printing (physical products), and breadboards (electronics). I’ll go into more detail on those another time. But first, a story about prototyping from a successful product company.</p>
<h2 id="realworld-example-dodocase_2">Real-world example: DODOCase <a class="head_anchor" href="#realworld-example-dodocase_2">#</a>
</h2>
<p><a href="http://www.dodocase.com/">DODOCase</a> makes iPad cases that have the look and feel of a hardcover book.</p>
<p>Founder Patrick Buckley, working on the first version of the product, needed to find a way to hold an iPad inside the hardcover book binding. His idea: hold the tablet in place with a wooden tray.</p>
<p>Pat created his physical prototypes using a device called a <a href="http://en.wikipedia.org/wiki/CNC_router">CNC router</a> which can carve a design created on a computer out of a block of material. Rather than buying one of these machines, he purchased a low-cost membership at his local <a href="http://www.techshop.ws/">TechShop</a> where he could access a CNC device.</p>
<p><a href="https://svbtleusercontent.com/3tvipffggo52q.jpg"><img src="https://svbtleusercontent.com/3tvipffggo52q_small.jpg" alt="P1000825.JPG"></a></p>
<p><em>(right) One of the first DODOCase tray prototypes, a very simple side rail with no space for cords. (left) The finished product, with a multi-part tray including cord cutouts.</em></p>
<p>One question he sought to answer with his prototype was: can a tray effectively hold the iPad in the book binding? Early versions of the tray failed at this, but he iterated on the design until he found one that held the tablet in place.</p>
<p>Another question he had was: how can the user access the power plug, audio plug, and volume buttons without the tray blocking access? He tried cutting gaps, but discovered that this weakened the tray and caused it to break too easily. He iterated on different thicknesses of the tray and size and shape of the cut gaps. He was thus able to explore the physical capabilities of his material and his design.</p>
<p>The DODOCase example demonstrates even physical products can do fast, cheap prototyping. Pat created dozens of prototypes over the span of several weeks, at a cost of about $500 (materials and a TechShop membership).</p>
<p>Pat’s story also helps us understand the true purpose of a prototype. In creating the prototypes he sought to discover the answers to questions about what was possible with the tools, with the materials, and in the design.</p>
<h2 id="prototypes-answer-questions_2">Prototypes answer questions <a class="head_anchor" href="#prototypes-answer-questions_2">#</a>
</h2>
<p>It’s important we understand that a prototype is not a finished product. The purpose of a prototype is to <strong>answer a question</strong> or to <strong>test a hypothesis</strong>.</p>
<p>A question for a software product could be: can we accommodate several different modes of operation on a single screen, or will the resulting design be too cluttered? Sketching out some designs as clickable wireframes may answer this question without even needing to user test.</p>
<p>A question for a physical product could be: what’s the maximum size we can make our product and still have it be comfortable to grip one-handedly? Creating a clay or 3D-printed prototype gives us an object we can hand to our test users and see how they hold it.</p>
<h2 id="benefits-of-prototyping_2">Benefits of prototyping <a class="head_anchor" href="#benefits-of-prototyping_2">#</a>
</h2>
<p>The number one reason to prototype is to test your idea with users, which I’ll discuss in a future post. But even before prototypes make it in front of users, there are many benefits for your team and your company.</p>
<p><strong>Prototyping helps us gather our thoughts.</strong> Even if you’re working on a small project just for yourself, the process of making something tangible that <em>shows</em> rather than <em>tells</em> what the product will do is extremely focusing.</p>
<p><strong>Prototyping helps us compare options.</strong> Sometimes it makes sense to create multiple, competing prototypes for comparison. It’s often the case that when we see several options side-by-side, it makes the best option dramatically apparent.</p>
<p><strong>Prototyping keeps team debates healthy and grounded.</strong> Meetings can go around in unproductive circles as the team debates abstract possibilities about what to build. Prototypes can help change this endless speculation (what <a href="http://www.mindtheproduct.com/2012/12/rapid-prototyping-google-glass-by-tom-chi/">Tom Chi calls “guess-a-thons”</a>) into a discussion about tangible details. Faced with a concrete example of how it will look and work, everyone on the team may instinctively agree to which option to pursue — and if not, it provides a basis for discussion about specifics rather than vague and abstract possibilities.</p>
<p><strong>Prototyping helps us get buy-in from stakeholders.</strong> If you’ve ever done contract work — that is, building something to your client’s specification in exchange for an hourly rate — you know how common it is that the client sees the finished product and says, “Yeah, I was picturing something a little different…” Prototyping gives us something that looks and feels something like the real thing, and lets us put it in front of stakeholders like clients, senior management, or people in our company who aren’t working directly on the development of this particular feature.</p>
<h2 id="conclusion_2">Conclusion <a class="head_anchor" href="#conclusion_2">#</a>
</h2>
<p>Prototyping helps us answer questions, test hypotheses, and get everyone in our company on the same page about what we’re doing. Prototypes are not products and we shouldn’t mistake them for such. In the next post, I’ll talk about the disposable nature of prototypes and how to select an appropriate level of fidelity.</p>