5 Users Will Tell You All You Need

@brentlarue on Jan 27, 2015


Welcome back to the insider’s track of General Assembly’s Product Management Course with George Favvas. Last week we learned about features, user stories, wireframes and storyboards. This week is all about user testing, a key tenant of user-centric design. In this session you’ll learn when and what to user test, how to conduct a user test, and understand user testing best practices. Let’s get it!

Usability Testing

First, why do we even bother with user testing? User test provide us with qualitative data that tells us how users perceive the product and value proposition, what is blocking users from accomplishing the set goals, what are opportunities to solve customer problems that were not thought of, and saves time and money by refining features before implementing them fully.

Second, when is the right time to user test? This answer may not be what you expect, but you don’t need a single line of code to user test. As soon as you have 2-3 use cases defined, you should begin user testing. In class, we sketched a fictitious app onto paper and broke into groups to test our paper prototype. In the spirit of the lean movement, you should create a product with the least amount of work which provides the greatest feedback. A paper MVP is a good place to start. Don’t believe me, try it yourself.

Depending on the maturity of your product you may want to test different things. Your usability testing should be in line with the same metrics you are trying to move along your funnel. If you are still working on the acquisition piece of your funnel, you may not want to user test the shopping cart experience. Be mindful of your funnel, product maturity, and customer adoption.

“Elaborate usability tests are a waste of resources. The best results come from testing no more than 5 users and running as many small tests as you can afford.” ~ Jakob Nielsen

Before you ever get into user testing, you must first recruit users. The method and approach to doing this comes in many flavors. You can expect to need at least 1-2 days before the test to recruit your users. Depending on your budget, you can use an agency, craigslist “gigs” section, or your own social network. Depending on your approach you will need some sort of screener to ask qualifying questions. To encourage participation, offer $50-100 Amazon gift cards for a 45 minutes session. These are super simple and cost-efficient to distribute to your participants.

Now for the test itself. Be sure when performing the test, be sure to take notes or record video. Some sample questions include: What do you think this product will do for you, would you be likely to continue on, why? While conducting the test, be sure not to include steps you feel are obvious. Pause on each wireframe or screen and solicit some responses. Point to specific aspects of the design, ask what they think it means, have they seen anything like this before, or what would they do here. You want to draw out gaps int he design or opportunities to improve. Consider asking if anything has surprised them, if they are seeing what they expected, what they expect to see next, and what they think the purpose of specific content is. If they get stuck don’t rush the test, allow some time for contemplation. Get comfortable with a little silence and then help them along. Long pauses could also indicate areas of confusion.


Lastly, how many users should I consult for testing? The answer – FIVE. Not surprisingly, zero users give you zero insights. With only a single user test, you can learn almost a third of what there is to know. The difference between zero and one user is huge, so there is really no excuse for skipping user testing. With the second user, you’ll uncover some overlap and some new insights, but not to the same degree you did with the first user. The third user will start to solidify feedback and provide relatively less new info. As you add more users, you will learn less and less. After the fifth user, you are wasting your time observing the same findings and not learning much new (consider The Pareto Principle). Check out the original research to learn about iterative design, why not test with a single user, and when to test more users.

That about wraps it up. Good luck with your users tests. Like and share below!

Jog of War Pitch on Slideshare

@brentlarue on Jan 17, 2015

The Pitch

Human beings have been at war since the dawn of time. We’ve left our homes to conquer new lands in parts unknown. We’ve declared war on our own to fight for independence. We’ve fought against enemies to defend a way of life. We’ve enlisted hundreds of thousands of people to defend their flag. We’ve seen economies both rise and fall as a result of war. And we’ve raised gazillions of dollars to fund war efforts. Through all of this, one thing is immediately clear.

We are motivated by war!

On the other hand, there is Alex. Alex is a computer engineer. He works all day in a cubicle, under those awful florescent office lights, behind his blue lit screen. When Alex goes home, he turns on the TV or cracks open his computer to browse Hacker News and play his favorite computer game. You could say Alex has a sedentary lifestyle. For Alex, exercise is an afterthought. It’s boring, takes too long and is uncomfortable. He knows it is something he should do more of, but only manages to run a couple times a month.

But Alex isn’t the only one.

Since 1960, jobs requiring moderate physical activity have fallen from 50% to 20%. That means 80% of us are spending the majority of our day stagnant, most likely in an office chair behind a computer.

Okay, okay, but I get my exercise in outside of work… right? Wrong. Less than half of adults are meeting the basic physical activity recommendations. That is equivalent to 150 minutes a week of moderate physical activity such as walking or 75 minutes a week of vigorous physical activity such as jogging.

So why does this even matter?

People who are physically active live longer, have lower risk for heart disease, stroke, type 2 diabetes, depression, and cancer. It also helps those of us who are more vain with appearance and weight control and those of us who are more ambitious to improve intellectual function.

With that being said, the solution to make physical activity more compelling could not come at a better time.

And thus enters Jog of War.

Jog of War is a massively multiplayer, real-world strategic running game where players claim, steal, attack, and defend to compete for real-world territory.

The name originates from the Startcraft-style fog of war where a player removes the fog as they navigate to new territory. Much in a similar fashion, players here remove the fog to discover enemy-occupied territory and hidden power-ups as they run around int he real world.

The Core concept of the product takes those basic instinctual motivations we know drive us and places them in a game that is both engaging and fun. Thinking back to Alex, my research has shown that his interest to get healthy us only a secondary motivation. His primary motivation is gameplay.

Game first, fitness second.

I’ve spent a great deal of time perfecting the mechanics of the game. Players are assigned to one of two teams so they can compete individually or contribute to the success of their team. Once you pledge your allegiance, the game is simple. Hit the ‘Start Run’ button and go for a run. The app will claim all the territory inside of your loop. If you run in a line, then you are missing out. You are again incentivized to go exploring, have fun, and break up the sometimes boring activity of running. You can steal your enemy’s territory by running over their tiles. This immediately transfers his territory to you. You can defend territory by running over your already claimed territory again. This means an enemy will have to run over it twice to claim it as his own. Attack enemy territory by running over their tiles once to reduce their defenses. Run over it again to claim the territory as your own. It’s that simple.

And for those of you that have your eyes fixed on world domination or looking to even a score, you can purchase power-ups in the app to claim, steal, attack, or defend additional territory.

So today, I am seeking health, exercise, and gaming enthusiasts to either fund or test my product. If you are interested in either, please get in touch and I would be happy to share my vision with you.

Thank you.

Blog readers: Sign up for beta now!

Productivity Quest: Ultra-Schedule

@brentlarue on Jan 8, 2015

For all of you looking to make some changes in the new year, check out Jessica Hische’s Productivity Quest: Ultra-Schedule. She gives some great advice for making the most out of your time and provides some practical tips on how to do so. I’ve been experimenting with my schedule for about a week now, and it’s a very welcomed change. Besides, if it’s good enough for Benjamin Franklin, it’s good enough for me.

Money, Models & Technology #PMLife

@brentlarue on Dec 20, 2014


What comes to mind when you think of the Silicon Valley — money, models, and technology. Wild success, raging launch parties, and disruptive technology are lurking around every corner. Well that is what the popular media will have you believe at least. Behind this facade, things look a little different. Moreover, behind every press release and every link-baity headline are some less sexy, but equally (often more) important content. So when I say money, models, and technology, what I really mean is pricing, financial modeling, and technology for product managers. The sex-appeal is in the eye of the beholder.

Pricing & Financial Modeling

For those who haven’t been following along with the series (and just clicked on the bikini-clad beach gals), this is part 7/10 of General Assembly’s Product Management course. In this session you’ll learn to build a working financial model for a given audience, describe different pricing approaches for a new product, and forecast demand and revenue for a new product.

So why is financial modeling important for product managers? Financial modeling gives the PM a forward looking view so that they can know they wont go bust, how much runway they have, if the product is sustainable, and/or when they will break even. The most fundamental financial view of a business is demonstrated by the financial tree below.

Profit Tree

Next, we were asked how would you price a 3D printer. After some discussion, we had a few options on the white board. The common four ways to price a product are cost-plus pricing, value based pricing, competitive pricing, pricing for innovative pricing. Cost-plus takes the cost of the product and adds some percentage margin on top. Value based sets the price based on the perceived value of the product. Competitive pricing takes the prices of similar competitive products into account when setting a price. Innovative pricing allows you to set your own price due to the innovative nature of the product. and While these are very business-school definitions, in reality, some combination of these methods are used for pricing.

In addition to setting a price, the pricing model must also be determined. Common pricing models for consumers include: one time fee (iWatch), subscription model (Spotify), and subscription plus activation (Weight Watchers). Common pricing models for B2B include per seat (SalesForce) and yearly license (Adobe). A common pricing model for eCommerce is revenue sharing (Etsy).

As for financial modeling, there are many ways to approach this with varying levels of complexity. I’m going to leave it up to @martinzych to describe how this is done as he did a very good job detailing his methodology — Intro to Financial Modeling.

Technology for Product Managers

“Never trust a computer you can’t throw out a window.” ~ Steve Wozniak

The question on most aspiring product managers is ‘do I need development experience to be a product manager?’ The simple answer is no, but you do need to have a foundational understanding of how products are built. This is key to create something that can be realistically built, build relationships with engineers, and understand the implications of the decisions you make.

Some basics we covered in class were what is a tech stack, technologies PMs use, and best practices for development. A tech stack is the combination of components and services that make up the software or application. This generally includes programming languages, frameworks, databases and cache. Some tech stacks have easy to remember names like LAMP (Linux Apache MySQL PHP) or MEAN (Mongo Express Angular Node.js), but it could just be Rails/Postgres or Django/MySQL/Memcache or Scala/Play/Postgres/Redis or any other possible combination (via Zapp42).

On a high level a tech stack includes UI, interactivity, data, server, code, and database layers. A good exercise for new Product Mangers is to define which layer the following belong to.

Tech Stack

Common technologies that should be in every PMs arsenal are Github, SQL, Jira, Google Analytics, MixPanel, Python, Ruby, HTML, and CSS. While these are not mandatory for the role, it is often helpful to know these so you can be self-sufficient.

Regarding best practices, PMs should always work closely with designers and developers. When making decisions with technological implications, don’t make the decision in isolation. Work with your developers to find the best possible solution. Both designers and developers should be brought in on the project as early as possible to establish a sense of ownership. Don’t impose solutions on you team, but involve them in decision making. As a PM, your role is not to decide how something should be done, but rather, what exactly must be done. Remember that designers and developers are experts in their fields and will be able to provide expert advice.

Thanks for reading. Share and Tweet below!

Customers: Who are they and how to get them?

@brentlarue on Dec 13, 2014

Product Management

In part 6 of 10 of General Assembly Product Management Series, we learned about conducting market research using various theories and frameworks, utilizing best-practices to determine who your customers are, what’s the potential of the market, and what kind competition you are up against. Once you know the who, you are able to tackle the how. How do we get customers to our product? Any successful product manager will tell you, if you build it, they will not come, you must bring them. In this session, we learned how to develop an effective customer acquisition plan using modern tools and actually launch a campaign for our product. This meant we needed something to drive people to. (Check out my product — Jog of War.)

Market Research

The learning objectives for this session were: Understand the SWOT analysis for a business, develop a competitive analysis of a product, and effectively size a market utilizing quick math and assumptions.

The SWOT analysis is a basic, but useful exercise of listing out the strengths, weaknesses, opportunities, and threats for your product or business. Strengths are internal in origin and helpful for achieving an objective (ie. experience, knowledge, resources, geographic location, etc.). Weaknesses are internal in origin and harmful for achieving an objective (ie. gaps in skills, financial issues, market awareness, reputation, etc.). Opportunities are external in origin and helpful for achieving an objective (ie. strategic partnerships, capitalizing on market trends, new product development, cost reduction, etc.). Threats are external in origin and harmful for achieving an objective (ie. industry shift, loss of a major customer, raw material cost increase, competition driving down price, etc.). While this may appear to be useless MBA non-sense, it turns out to be quite an effective exercise when the executed properly.


A very simple and practical competitive analysis involves: identifying key points of differentiation, researching competitors, and comparing your business to identify you strongest differentiator(s). We’ve all seen these on product/service offering pages, where the product or service being sold has all the check boxes checked while the competitors seem to have substantially less. The example below is from a 2007 version of Dropbox, but shows key differentiators for file sharing at the time and highlights what the competition offers. Again, a simple, yet effective exercise.


Market sizing is a bit more involved and can be much more an art than a science. There are two approaches when it comes to market sizing, top-down and bottom-up. We already learned previously from Khailee Ng of 500 Startups (5 Moves to Master the 3-Minute Pitch) that the bottom-up approach is a much more effective and believable method or market sizing. For example, don’t just list the size of the industry and assume if you only got 1% (a relatively small amount) of the market, you would have an x-dollar business. By doing this, you have not demonstrated that you know the market, how you plan to attain this 1%, or that you even know how significant that 1% is. By building a figure from the ground up, you establish credibility, demonstrate you understand the market, and show you have strategically thought about the significance of this target market. Market sizing can be in terms of users or revenues or both. A useful model for market sizing is TAM, SAM, SOM (Read more).

Customer Acquisition

Customer Acquisition is the first part of the funnel using the AARRR model (See Models, Cats & Pirates – A Lesson on Product Management). During the early stage of your product, this should be the focus of most of your attention, while during mid/late stage you must be aware that while it may not be the highest priority, it does affect all downstream metrics.

“It’s not about the idea, it’s about how prepared you are. Everyone has ideas, most don’t do the work required to get the job done. The second thing you need to know is that sales are the most important aspect of a small business. No sales, no company.” – Mark Cuban

There are two approaches for acquiring new users — viral and paid. Viral growth (K) is most often calculated using the viral coefficient while paid growth often utilizes a simple ROI calculation (LTV vs CAC). The viral coefficient is calculated as the average number of invitations sent by each existing user times the conversion rate of invitations to new users.

The golden rule for paid growth is Lifetime Value of a Customer (LTV) must be greater than the Cost of Customer Acquisition (CAC). Or more simply, the revenue from a customer must be greater than the cost to acquire them for a profitable growth strategy. For subscription models, LTV is equal to revenue per subscription times months times the average lifetime of a customer. For eCommerce, LTV is equal to average basket size time repeat sales times months times the average lifetime of a customer. Simple CAC is equal to the marketing cost of a campaign divided by the number of acquired customers. A more advanced CAC is equal to campaign costs plus wages plus software plus professional services all divided by the number of customers acquired.

There are many channels for paid advertising. A few examples are search engine marketing(Paid/Organic), Facebook ads, display ads/retargeting, Groupon/daily deals, street marketing, B2B sales, and direct mailers. For a more thorough list check out Dave McClure’s Startup Metrics for Pirates Slideshare (Slide 3).

Thanks for reading. Share and Tweet below!

Models, Cats & Pirates – A Lesson on Product Management

@brentlarue on Dec 12, 2014

Bridge created by iconsmind.com from the Noun Project

Welcome back to the inside scoop on General Assembly’s product management course. Today’s class was all about business models and metrics. Let’s skip the intro and jump right in.

Business Model Design

During the first part of class we learned about different types of business models, components of business models, how those components relate to each other, and how to develop a business model around a new product idea. Three common business models that dominate the digital world are e-commerce (Etsy, Amazon), subscription (Spotify), and ad-supported media (Gawker). And there are also companies with pre-revenue models (Snapchat, Instagram). More specifically, these business models describe the monetization of a larger business model canvas (or lean model canvas).

The Lean Model Canvas (a derivative Alexander Osterwalder’s original 2008 Business Model Canvas) looks something like this. (Download the Excel template)


The lean model canvas forces you to think about all aspects of your product, from what problem you are solving to how are you going to make money. Once you’ve taken the time to fill this out, you should work to identify your biggest assumption categories. As with everything in product management, do your best to test any and all assumptions. This will reduce your risk and increase your likelihood of success.

For practice, think of an existing company or product and work through the canvas. It is easier to evaluate an existing product than it is to create a new one. We ran into a case during our exercise where the user and the customer were different. This resulted in the majority of our solutions only solving the users’ problems while the customers were the ones paying for the product. This required us to take a step back and work through two canvases, one for the user and one for the customer, to ensure that no needs were ignored.

“If you’re going to put your product in beta – put your business model in beta with it.” – Joe Kraus, Google Ventures

Lean methodologies teach us the way to validate those early assumptions are by creating a Minimum Viable Product (MVP). An MVP is the least amount of work you can do to learn the most of something. As I said before, this reduces risk and maximizes success, but it also provides faster feedback, reduces overhead, and creates measurable progress. You do not need to code to test something.

The perfect example comes in the form of a cupcake. When couples go shopping for wedding cakes, the bakery doesn’t whip up a whole cake, but rather lots of cupcakes each representing the different options. Some types of MVPs that exist in the technology world are concierge (delivering a service manually rather than automatically), wizard of oz (delivering a product where behind the scenes everything is manual), landing pages (to measure interest), and video (to demo a complex concept) MVPs.

See also the Top 10 Business Model Pitfalls.


In the latter part of the class we learned about how to identify the right metrics/KPIs, tools to use, the conversion funnel, and how the funnel stage determines what should be tracked. First things first, what is a KPI? A KPI or key performance indicator is a type of performance measurement. It is used to evaluate the success of a product, organization, or activity. When defining metrics, keep in mind that a good metric is always understandable, comparative, a rate or ratio, and behavior changing.

As Product Managers, there are many frameworks at our disposal, but one that has been readily adopted and used today is called Pirate Metrics. This framework developed by Dave McClure uses the acronym AARRR to represent Acquisition, Activation, Retention, Referral, and Revenue. Activation is concerned with getting the customer. Downloads or signups is a good metric to measure this. Activation gives them a positive experience with the product. The metric here is often contingent upon the product, but can be something like sharing a photo or posting a status update. Retention is all about bringing them back. Daily active users (DAU) over monthly active users (MAU) is a good metric for retention. Revenue is all about money. Metrics here are all centered around making money. Referral is about virality. Metrics include number of invites per user, conversion rate of invites, and the viral coefficient.


Metrics are not only for measuring success, but also can be used in prioritization. When identifying your key metrics, also determine what an appropriate target is for that metric. Do some research to identify what is an appropriate target. The book Lean Analytics provides a lot of useful ways to go about doing this. If you haven’t noticed already, Pirate Metrics sets up a conversion funnel. By identifying the areas on your funnel where your metrics fall short of the targets, you can begin to prioritize your efforts. Always start higher up on the funnel when making change to your product. If you aren’t making any money, you don’t want to change you monetization strategy until after you have found a way to drive people to your product.

Useful tools and resources: Google Analytics, KISSmetrics, Compete, Flurry.

It turns out cats don’t have much to do with product management. But they are awesome! Thanks for reading. Share and Tweet below!

It’s Going Down at #StartupAsia

@brentlarue on Nov 26, 2014


The Startup Asia conference is live and in full-swing in Jakarta. Day one wrapped with lots of interesting speakers covering a wide array of topics from petting tigers to how startups can be successful in the Indonesian market. The booths were buzzing and founders were sweating preparing their pitches for investor speed dating. Two of the most notable presentations coming out of the Kickstart room were Ana LaRue’s fireside chat speaking about Path’s success in Indonesia and Khailee Ng’s 5 moves to master the 3-minutes pitch.

Path’s Success in Indonesia

Ana LaRue is a Marketing Manager at Path, a San Francisco based startup focused on bringing happiness, connection and meaning to personal life through design and mobile technology. Ana works on growth, engagement and marketing related projects and is currently living in Indonesia, where she is helping Path set-up a local office. Ana has extensive experience in online marketing where she worked in publishing and impact investing sectors.

Path is making big strides in Indonesia. Their presence here is a sign that there is much more to come for Indonesian users. With the goal of hiring a country manager and setting up an office Indonesia, Ana says Path is dedicated to understanding and catering to the Indonesian market. Plans are in the works to collaborate with brands and form strategic partnerships with Indonesian companies to help foster growth in the nation. Already, Path has worked with local Indonesian artists to create stickers used in their messaging app, another way which Path has worked to delight their users. But the growth Path has seen has not come without it’s challenges and change doesn’t always come easy. Rest assured, Ana says Path is paying attention and committed to creating meaningful experiences for it’s users, especially those in Indonesia. Stay tuned on what lies ahead on the Path blog.

500 Startups’ 5 Moves to Master the 3-Minute Pitch

Khailee Ng is Managing Partner at 500 Startups. His focus areas include global expansion, managing the Southeast Asian fund, and building bridges between emerging markets and Silicon Valley. Born and raised in Malaysia, he started creating web products at age 15. By the age of 30, he built a news company SAYS.com (now listed in the Malaysian stock exchange as REV Asia) and ecommerce company GroupsMore (acquired by Groupon). He hopes to create tomorrow’s game changing companies by providing people from anywhere in the world with equal access to global resources and opportunities.

The charismatic Khailee took with stage brooding with excitement. For all the young founders in the room, Khailee shared an excellent framework for creating a consice and effective pitch. His approach approached the art of pitching from a different angle. Don’t think about what you want to say first. Instead, think of the reactions you want to get, and then form what you want to say around those.

His framework defines those 5 effects as:

“I want to know more”
“What a great idea”
“This is going to be huge”
“This is the team to do it”
“I want to be part of this”

Some key strategies to doing this are amplifying the problem. Once the problem has been clearly defined, take a small problem that a specific user had where you were able to effectively provide a solution. Once you do this, juxtapose this small problem to a larger audience. Next, get into some number, but don’t try to dazzle the audience with huge market size numbers with top-down thinking, but instead think from the bottom up. How many users will you foreseeably have? How money do you make form each user? And there you have a reliable and believable number. To further establish credibility in the figure, speak about how many users you already have and how you were able to acquire them (via Pinterest, Twitter, Launch page, etc.). Build onto this number by describing how much you expect to grow and what that means for the monetary value of your venture.

Next, describe you team. But don’t just list the names and positions of your team, calling them pirates, ninjas, or whatever. Instead, start by describing what competencies are needed to make this successful and demonstrate the unique quality of each individual and how they are the best team for the job. Lastly, let the audience (users, media, investors) know how they can be a part of it. There are many ways to achieve this effect, whether by emotional appeal or reiterating you vision, but you want to qualify who you want to be involved specifically. Throwing a huge net will make you appear desperate and without a plan. Become desirable by pre-qualifying the investor you are looking for and the type of user you hope to satisfy.

And there you have it, looking forward to an exciting day two. Be sure to tweet and share below!

Inside General Assembly’s PM Course Day 03

@brentlarue on Nov 25, 2014

Product Management

Alright, I’m back with the insider’s track on General Assembly’s Product Management Course with George Favvas. This week, we took a dive into features, user stories, wireframes, and storyboards. The class was chock-full of good learnings. We kicked off the session reviewing findings from our user interviews. A lot of my colleagues (including myself) learned their product idea was actually a solution in search of a problem. What a great time to learn this before having spent significant time and money building the wrong product!

Features & User Stories

Product features are not something that are arbitrarily decided. They are not creative ideas that a design or marketing team invokes, they are not cool technology implementations the development team comes up with, and they are not new and exciting add-ons the product manager dreams up. Product features are derived to address a specific want or need of a user. Each of the roles above fall into the trap of doing what they do best — designing, developing and managing, but this more often than not is the wrong way to approach feature inception.

We went through an exercise of evaluating a familiar product, Gmail, to describe what needs are already being addressed through current features and what needs still exist with the current product. As we listed out the basic needs, one of which was sending emails, it became clear which features were created to solve those specific needs. For example, as a user, I need a way to create a new email message. The feature derived from this need was the “compose” button. This exercise brought about a lot of discussion on current frustrations with the product including both real wants and needs of users. These wants and needs were later translated into very practical features (Google, we should talk!).

The Gmail exercise naturally led into the definition of a user story. For those new to Product Management or Agile Development, a user story is a short, simple description of a feature told from the perspective of the person desiring the new functionality.

As a <type of user>, I want <some goal> so that <some reason>.

I like to think of user stories as the building blocks of your product to be used by all parties of the team so they may begin to understand and work on the product. User stories (along with personas) continue to drive home the user-centric thinking on your product, one of the key tenants of a successful product. To make that point clear, George provided an intriguing example using Raid bug spray.

When Raid was first launching its product, it had a formula which was 99.9% effective in terminating bugs. However, despite the effectiveness of the product to terminate bugs, sales were plummeting. It wasn’t until user research was conducted that it was discovered users had the expectation of actually seeing the bug die in front of them. Whether this expectation was created by advertising or not is a moot point because the product was suffering as a result. Upon learning this, Raid adjusted their formula so the bug would die instantly and the product sales surged.

Wireframes & Storyboards

In this session, we learned about the different levels of fidelity in wireframes, the importance of and how to create wireframes, and storyboarding.


Wireframes comes in many forms from napkin sketches to hi-fidelity, fully annotated wireframes. Each level of fidelity serves a specific purpose. Sketches generally serve as an exploration where the designer or PM plays with different ideas and stimulates thought. Lo-fidelity wireframes establish the conceptual design where features are realized, layout and composition defined, flow is established, and hierarchy of information/functionality are displayed. Hi-fidelity wireframes are polished versions of the wireframes which include all the information/functionality in the correct place and size. These wireframes should include annotations describing any interactions, transitions, functionality, etc.

All wireframes are intentionally void of visual design so that feedback is entirely focused on flow, layout, hierarchy, information architecture, composition, usability, etc. It may be tempting to splash some visual design elements in at this stage, especially if the UI designer has got a jump-start, but this will only distract at this stage. It is also worth mentioning there is no wrong time to solicit feedback from users. While soliciting feedback, it is important not to lead the user. Learn to be comfortable with the long pauses so that you don’t guide the user. While conducting the session ask questions like: what do you think is the purpose of this screen, what do you want to do here, what do you expect to happen when you perform that action? Be careful to observe what the user wants to click on even if it wasn’t designed to be a clickable area and remember no to be defensive of your product. This process takes practice and skill that takes lots or repetition to improve so ultimately you will solicit the best and most meaningful feedback.

“Understanding and usability over pretty.”

There are some limitations to wireframes however. It can be difficult for the user to envision the end product. Also without any form of visual design, some elements which can be made obvious via visual treatment may get lost in the wires and alter the way the user would actually interact with the product. Despite these limitations, wireframing is a key step along the process and one in which can provide a lot of valuable information to PMs and their teams.

Finally, storyboarding is the process where sketches or wireframes are outlined in the sequence that a customer will experience while using your product during a specific activity. This provides context and allows the users and your team to explore the complex interactions. It helps identify not only the happy path, but also the unhappy path where error messages, additional screens, or more creative solutions may be required. The unhappy path, if left unattended, can be the root of lots of frustration from your future users.

If you enjoyed the post, share the love! tweet and share below. Thanks for reading.

General Assembly – Product Management Day 02

@brentlarue on Nov 14, 2014


Alright folks, welcome back for week two of San Francisco’s General Assembly Product Management course. Last week we all came up with product ideas that we would develop throughout the course. We had ideas all over the map from a children’s toy discovery app to a panic attack prevention product. For my product, I will be re-visiting an idea that was put on the back-burner while working with my pals over at Mediately (formerly Modra Jagoda). The product, Jog of War, got its roots from Health 2.0′s Berlin Code-a-thon back in 2012, where it took first place and made it to the grand stage to be presented by our very own Jure Triglav. I’ll get into the details of the product on another write-up, but for now I want to focus our attention on the course. This week was all about Users and Customers (yes, there is a difference)!

“We are not smarter than the collective intelligence of our customers.”

Part 1: Customer Development

The objective of this class was to identify our target users, learn how to conduct successful user interviews, and understand the user’s needs, behaviors, and current ways of working. We kicked off class with a short clip from Steve Blank, a Silicon Valley serial-entrepreneur and academic recognized for developing the Customer Development methodology, which launched the Lean Startup movement.

What Steve is trying to teach us is that before pursuing any wild ideas, we need to test our hypothesis and assumptions with potential customers. The aspect of this which resonates in my mind is “get out of the building.” Part of our homework assignment was to do exactly this. First we had to identify our target customer. Once we felt we had a grasp on this, we had to identify where we could locate these individuals. And finally, we had to actually go out and talk to them. This is the part that can be the most uncomfortable, but also the most rewarding. It isn’t until you actually go and talk to potential customer’s do you begin to remove yourself from the picture and understand the actual problems people are having. After all, a solution to a problem which doesn’t exist, isn’t really a solution at all.

Stay tuned for another post where I share my findings. This was an awesome exercise which fundamentally changed they way I would approach my product moving forward.

During the class, we had a visitor and former GA student Chris Dyball Noble, Head of Product at Blinq, share his first-hand experiences with interviewing and walk us through a mock interview. Through the interview, Chris talked us through a few key lessons:

  • Make sure you are not introducing sample bias or a self-serving bias by selecting too narrow a customer profile.
  • Let the interviewee know that you are building the product in question so they take you seriously.
  • Let them know up front how long it will take and offer some incentive if possible (Amazon gift cards work great).
  • Some things you can’t solve, but being empathetic helps build trust and a conducive interview environment.
  • During early stage interviews, broad, open-ended questions can help you learn the fastest.

Part 2: Personas & Empathy Maps

The latter portion of class was focused on what happens after the interviews — translating your interviews into personas, creating empathy maps, and learning how and when to apply these tools.

A persona is an archetype of a group of users. It does not represent one person. It is created by identifying trends in user research. While these are fictitious people, they are still rooted in reality. Personas help UX designers, marketers, product teams, and executives think and make decisions like their potential users, not themselves. It is not always the case that you will be your own target user. Within a persona, you should capture goals, needs, behaviors, pain points, scenarios, biographical info (name, age, gender, location, income, etc.), and maybe even personality traits. Finding a picture to go along with the persona can help make it more memorable and real. We also learned how to create and use empathy maps, though truthfully, it does not sound like these are used as frequently in everyday life.

To wrap up class, guest speaker Cheryl Yeoh, CEO of Malaysian Global Innovation & Creativity Center and formerly Walmart Labs via Reclip.It, talked to us about her product experience. Cheryl walked us through some of her early mistakes including working too long on ideas without first validating them with customers. It was refreshing to hear her talk about her “stupid idea” and the struggles that she and most founders grapple with. Eventually, Cheryl and her team would turn around the company and later be acquired by Walmart Labs — well done! Identifying and collaborating with Mommy bloggers (after discovering some traction through analytics) was a big part of growing the product. Another really interesting event which took place was bringing in two users, one old and one new, every Friday to test the product. Overall, she really helped us understand that this was not academic bullshit, but this was the real deal.

Another great class under the belt! Until next time, over and out.

General Assembly – Product Management Day 01

@brentlarue on Nov 5, 2014


Last Saturday was the first class in General Assembly’s San Francisco Product Management 10-week business course. The course covers all areas of product management from user research to financial modeling. Over the course of 10 weeks, we the students will work to launch real products. By combining theoretical knowledge with practical, hands-on learning, this course will take us through the rigors of creating and managing products.

“General Assembly is a global community of individuals empowered to pursue the work they love.”

Our fearless instructor George Favvas, CEO of San Francisco’s PerkHub and his trusty side-kick Pat Pow-anpongkul, Product Manager at Trulia, will lead us on our journey. Our class is full of students from all walks of life — new grads, venture capitalists, entrepreneurs, project managers, and engineers. Each one of us has our own motive from formal product management training, changing career paths, taking on management responsibilities on current teams, to getting a startup off the ground. It’s going to be an exciting 10 weeks and I’m looking forward to learn how to create and manage great products together with an ambitious group of classmates!

Part 1: Introduction to Product Management

In this session we learned what are the multiple roles and responsibilities of a Product Manager. The highlight of the lesson was the paired exercise where we took a fictitious app and identified needs, features, and benefits for various user groups. This exercise started laying the ground work for future lessons and beginning to think like a Product Manager. With user groups such as grandparents, parents, and friends, we had to understand that in all decision making as future Product Managers, we lead with certain assumptions. By first understanding the assumptions we are making, only then can you begin to establish ways of validating those assumptions. Upon sharing our results, we began to see the benefit of creating a detailed set of personas to help drive features and value for the users. Off to a good start!

Part 2: Product Development Cycle

The second part of the course, we learned about the product life cycle and the development stages teams must work through. An exercise we used to further our understanding included sticking post-its of different companies on the product life cycle graph drawn on the whiteboard (development, introduction, growth, maturity, decline). For companies like MySpace, the task was pretty easy (sorry JT). For others we had to dig a little deeper into key metrics like cost of acquisition, revenue, rate of revenue growth, and AARRR metrics to peg them accurately. This is a great exercise for any product manager (new or old) while reading the newspaper to think about where companies/products fall along this life cycle. It can provide an interesting lense into the what other product managers are doing, when they are doing it, and then ultimately why they are doing it.

Another valuable framework for understanding products and the stages they go through was the technology adoption lifecyle from Geoffrey A Moore’s Crossing the Chasm.


As Product Managers, we must balance lots of different priorities. By understanding where you are along the life cycle, it will help identify what is of greater importance. It’s important to know where you are in terms of your customer’s adoption of the product as well. Innovator’s and early adopters will endure much more than your later users. In general, we learned that as you get more and more adoption, features, usability and affordability all improve.

We also took time to examine three technology development framworks: waterfall, agile, and lean. Each has their merits and appropriate applications. There is plenty of writing on this on the interwebs so I’ll just leave it at that.

Other take-aways from class:

Monthly Active Users is the main metric for any consumer app which is non-transactional. If transactional, use revenues.

To measure quality of engagement use DAU/MAU. This metric tells you what percentage of people using your app this month will also use it today. Facebook has a percentage in the range of 50-60%. Anything over 30% is good.

The Holy Grail of continuous integration: Commit, automated test, automated sample deployment, automated a/b testing, automated deployment when test group key metric is greater than control.

Facebook dropped their motto “move fast and break things.” This is a sign that they are out of their growth phase.

Stay tuned for weekly updates on General Assembly’s Product Management course. Thanks George for a great Day 01! Over and out.