business Tag Archives - General Assembly Blog

It’s virtually impossible to develop a successful product without knowing who’s going to use it. Enter customer development, the practice in which product managers and user experience (UX) designers interact with customers to learn more about their problems in order to create a product that meets their wants and needs.

Customers include any current or prospective people who buy, use, or support your product. When product managers understand their customers, their problems, the environment in which those problems occur, and the value of solving them, the products will very likely succeed.

Imagine you’ve joined a team to launch a new mapping product for field technicians who inspect oil and gas assets (e.g., oil wells, pipelines, valves, etc.). In many cases, the assets are located in rural locations far from paved roads. The initial hypothesis is the technicians will buy a mapping solution that displays an asset’s geographic location and basic information on a map. In order to test this hypothesis using customer development, you spend several days in the field with customers. During that time, you learn that the technicians already have ways of displaying asset locations on a map, making your proposed solution not valuable.

However, during your time in the field you observe a more challenging problem: the technicians driving to the assets. While sometimes an asset may be only 200 feet off the road, if it’s on the other side of a creek or a hill then it could be 10 miles or more to drive to it. Many technicians rotated through assets and didn’t know the best way to get to them, and finding a path could waste several hours in a day.

The technicians wanted a way to mark how they get to an asset on the map as they were going to it, so each technician would know the best route for future inspections. This would save time and fuel, as well as reduce greenhouse gas emissions. Based on this information, you add waypoints — the ability to mark points on the way to an asset — to the initial product release.

In this example, customer development early in the product life cycle ensured the product would solve a challenging customer problem.

Customer development starts before the first piece of code is written and continues until the product’s end-of-life stage. As the product progresses through its life cycle, the tools used with customers increases in fidelity from simple sketches, to wireframes, to mockups, to code. The continual customer interactions ensure product managers accurately represent the voice of the customer at each stage.

The product development life cycle has seven phases. During the Conceive and Plan phases, customer development interactions usually consist of interviews, sketches, and wireframes. As the product moves into the Develop phase, the most common interactions are mockups, proof-of-concept code, and beta releases. During the Launch and Iterate phases, the product will expand to solve more customer problems using all of the customer interaction tools. Customer development is important in the Steady State and End-of-Life phases to make sure customers continue to buy the product and can eventually easily migrate to a new solution.

By interacting with customers early and often, customer development increases the understanding of customer problems and how they value them, and provides useful information to turn into potential solutions. By using hypotheses, the most important customer information is identified and collected. The results from practicing customer development are used to prioritize product development and ensures you build products your customers love to buy and use.

Customer development is a core practice in developing profitable solutions with product-market fit that customers love to use. At General Assembly, we cover this early in our part-time Product Management course and reinforce it throughout to ensure that students learn how to apply the appropriate tool to match the situation.

In the course, students select a product idea to use for their course project. Once they identify their target and develop some initial hypotheses, they start the customer development process. As they develop their projects, continual customer interactions ensure they are on target to graduate with a clear and compelling example of the skills learned. Many times, these projects are a critical differentiator as they make a career transition into a new field.

Students in our UX design courses — the full-time Immersive program or part-time on-campus or online courses — also cover elements of customer development through skills like user research, usability testing, customer journey mapping, and more.

Alex McCarthy, a Product Management instructor at General Assembly’s Austin campus, has worked in product management, software development, marketing, and sales roles, at companies ranging from early-stage startups to global, publicly traded companies. Alex has expertise in areas including oil and gas, measurement and automation, Internet of Things (IoT), professional consulting services, and more. He built successful product management and marketing teams for embedded hardware, enterprise software, and web application solutions.

Coming from a long line of teachers, he is passionate about education. He has mentored in public schools and served on various school boards, committees, and organizations. He recently founded Navigate Next, a company dedicated to helping leaders navigate to new careers in which they’re more passionate and engaged.

Let’s say you want to create a wedding cake for someone, but you’re not sure exactly what they want that cake to be. There are far too many variables involved to just jump into creating a full three-tier, fondant-covered, fully decorated cake, right? You’d have to choose what kind of cake, filling, and frosting, what colors should be on the cake, how the cake should be structured, and so on.

So how do we know what the customer wants, and how we can delight them with the perfect cake for their perfect occasion? It’s simple: We start with a cupcake. It’s small, easy, covers all the necessary bases, and confirms what the customer wants before we fire up the bakery and decoration team to create the final product. That cupcake is our wedding cake MVP.

The term MVP, which stands for “minimum viable product,” is widely used throughout the product development world. The term dates back to the early days of Agile product development and was coined in 2001 by Frank Robinson, now CEO of the product development firm SyncDev. It has since been popularized throughout the industry by such authors and thought leaders as Steve Blank, Marty Kagan, and Eric Ries. As such, it’s become somewhat of a buzzword — and like many such buzzwords, it is often both misused and misunderstood.

The basic concept of a minimum viable product is simple — it’s the smallest amount of work you can do to deliver something of value to your market. It’s something that can be used to validate (or invalidate) a specific set of assumptions, to derisk potential complications in your go-to-market plan, and/or to test one or more specific hypotheses about your target users. Keep in mind, though, that the more you’re trying to do with your MVP, the less likely it is to really be an MVP.

Understanding what an MVP really is and why it’s important is critical to the success of most startup businesses and for the career trajectory of someone who wants to be a product manager. Product managers must have laser focus and ruthless dedication to focusing their organization’s efforts of achieving its MVP before iterating on it, and ensuring that each subsequent iteration is itself an MVP.

The easiest-understood aspect of an MVP is that it is, in fact, “minimal” — meaning it reflects the smallest amount of work needed to test your hypotheses or solve a user problem. However, this is often difficult to achieve in practice — during the product development process, nearly everyone involved will want to add to the MVP, but nearly nobody will be willing to subtract from it.

Product managers must be able to mercilessly cut scope and fight feature creep in order to keep the product team focused on delivering the MVP. I once read a great thread on Quora that addresses this by imagining hypothetical discussions with the product manager for Dropbox — in my opinion, one of the best examples of a true MVP. You put files in a folder, and they synced to the cloud. That’s it. Some stakeholder probably asked about user rights — and the PM probably answered, “It doesn’t do that.” Someone probably asked about syncing multiple folders, and the PM answered, “It doesn’t do that.” Ruthless dedication to delivering exactly the minimum set of features needed to delight its users really allowed Dropbox to have exceptional success in a market that many had tried previously to conquer.

After we establish the minimum set of features we should be building into our product, we have to make sure the product is actually viable. Essentially, this means that it solves an actual problem that people have, and the product is constructed in a way that’s useful to those people.

If your MVP can’t stand up for more than a few hours without manual intervention, it’s not viable. If your MVP has such a poor user interface that people can’t intuitively figure out how to use it, it’s not viable. If your MVP takes longer to solve the problem than the method that people are currently using, it’s not viable. If your MVP can’t be used by more than five people at a time, it’s not viable. All of these things might start to sound like “scope creep” — more functionality that is absolutely necessary to achieve your goals. But the important thing to note is that security, user experience, and scalability are not features to be cut to reach your MVP; rather they are fundamental aspects of your product that you simply have to implement in order to actually have an MVP.

Finally, an MVP must actually be a “product” — that is, it has to be something that solves a valuable problem across a wide enough market space to be feasible as a moneymaking proposition. If you’re making an MVP that suits a small number of people, it’s probably a tool rather than a product. If you’re making an MVP that nobody is actually willing to pay for, you’re doing charity work and not building a product.

Now, keep in mind that the user doesn’t have to be the one paying for it — Facebook makes billions of dollars on the backs of its advertisers while its users engage regularly for free. But you do need to have some concept of who will be willing to pay for your product, and evidence that this path is sustainable.

At General Assembly, understanding the concept of MVP is a core component of our part-time Product Management course. Students engage in coursework and exercises that force prioritization decisions, backlog management, and stakeholder negotiation. The course’s final project is a pitch for an MVP solution to a valuable market problem, which sums up all of the skills and capabilities developed over the 10 weeks in class.

Whether you’re starting a new project, evaluating the state of your business, or trying to decide how viable a new product might be, here’s a remarkably simple yet powerful tool that can help you move forward: SWOT analysis.

SWOT is a strategic planning method structured on four elements of concern —  strengths, weaknesses, opportunities, and threats. SWOT can be terrific tool for strategic planning, and it helps to better manage the future of a product or organization. It’s often used by product owners, marketing managers, and business analysts, but may be undertaken by entrepreneurs and other business decision-makers as well. A SWOT analysis can benefit a business at any stage, and its popularity has driven its use to noncommercial organizations, industries, and even entire countries.

A SWOT analysis is often created during a strategic planning session as the result of brainstorming exercises. It can be constructed quickly and the results are usually broad and simplistic, but they can help jumpstart discussions of strategic priorities.

A SWOT analysis includes factors both internal to the company and outside in the greater environment. Strengths and weaknesses are internal. They are the things the organization does — or doesn’t — do well. Recent research has shown that these are the most important factors, and they’re within the organization’s control. For instance, when performing a SWOT analysis on a company, the internal factors may include the organization’s people and culture, client and vendor relationships, physical plant and equipment, financial assets, manufacturing prowess, intellectual property, marketing capabilities, and beyond.

Opportunities and threats are external factors. These are the forces that are outside the organization, but could still have a significant impact on the ability to reach the stated objective. For a company, these may include competitors and vendors, technology, macroeconomic trends, government policy and regulations, changing demographics, and more.

SWOT analyses have emerged as a valuable approach because they’re fast, flexible, and give a quick overview of the company’s situation. The method works like this:

1. Clearly state your objective.
2. Identify strengths — things you do well that may help reach the objective.
3. Identify weaknesses — areas that need improvement and may hinder you.
4. Identify opportunities — places ripe for growth or advantage moving forward.
5. Identify threats — competitors or conditions that could harm your efforts.
6. Recognize relationships between the identified elements.
7. Prune and prioritize to those topics you can focus on to drive change going forward.

The elements proposed in a SWOT may be wide ranging, yet the analysis must be realistic and rigorous. SWOT is a strategic tool. It is about planning for the future, so focus on things that could actually impact reaching the stated objective.

Threat of new upstart competitor? Yes.

Threat of zombie apocalypse? Not so much.

A SWOT analysis can help reveal issues and determine whether the desired objective is feasible in the operating environment. SWOT results can be simply listed or shown in a series of columns. However, the most common representation is a matrix like, this:

A SWOT analysis can be used early in a strategic planning session as a conversation starter to surface issues like market positioning or technology changes. Or, it can be taken deep and used as a more comprehensive study.

As a planning tool, SWOT analysis can utilized at many levels. It can be used to:

• evaluate a product,
• appraise a line of business,
• assess a team, or
• analyze an entire organization.

At General Assembly, students learn about SWOT analysis in our User Experience Design Immersive in the unit on business analysis. It’s also covered in our part-time Product Management course, as it’s key in understanding the path to product-market fit. Students are taught to be aware of the competition and what they are doing, but to not let that be the only determinant of what your product should be. They must also appreciate the assets they have to leverage and how it all fits together.

Jason Reynolds teaches the User Experience Design Immersive program and related workshops at General Assembly’s Boston campus. He is passionate about user experience and process improvement and is excited to share his knowledge and experiences with others — especially those new to the field of UX.

We all know the products that are successful; the ones that seemed to come out of nowhere and then change the way we go about our lives — like the smartphone, ridesharing, or turn-by-turn navigation. But there are a lot of products that didn’t make it. Though there are many reasons why products aren’t successful, one that often comes up is that people don’t see value in what it does. Or, they don’t see enough value in it to pay for it.

One way to avoid going down that path is by conducting user interviews. This is where product teams go out into the world and talk to people who fit their product or service’s personas, observe their behavior, and ask them questions. A persona is a representation of users who have the same problem or goal. Though personas are not real people, they are created based on real user data, often generated or validated by user interviews.

User interviews were introduced in 1990 when the authors of a report called Contextual Design: An Emergent View of System Design talked about “contextual inquiry” as part of the product development process. The goal of an interview is to discover what problems users have that product teams might be able to solve. This is done by visiting users in the environment in which they use the product or a competitor product, or where a problem is occurring; watching their behavior; asking them questions about their behavior; and then drawing conclusions from what they observed.

Anyone and everyone on a product development team — including product managers and user experience designers — is encouraged to take part in a user interview at some point. It’s very easy for teams to get caught up in their own assumptions around what products users want or need. By observing real people, in context, experiencing a problem, team members build empathy and have a strong desire to personally solve it. So the act of interviewing can result in not only more successful products, but also more inspired teams who find meaning in their work.

Oftentimes, user interviews are criticized as “asking users what they want.” That is a misnomer and not the true objective. As researchers, the goal is always to observe current behavior so that we can understand as much as we possibly can about the problems users experience, relative to the solution we’re able to provide. We try to prove that the problem is real, in what context it occurs, how a user currently solves the problem, the frequency with which it occurs, and how frustrated a user is when it’s occurring.

Critics will often add that they understand problems enough by looking at analytics, or quantitative data. Unfortunately, quantitative data can only tell you that there is a problem — it’s qualitative data that will tell you what that problem is and why it exists. The insights the team gets from truly understanding and empathizing with the problem allows them to think more broadly about their solutions and truly build the next set of innovative and successful products.

A key step in planning user interviews is, of course, finding your users or potential users. Sometimes seeking out people who are willing to talk to you can be as simple as doing an intercept interview, where you approach people on the street, in a place of business, or digitally while they are using your product, and ask them if you can have a few moments of their time. It’s OK if they say no! Simply move on to the next person (who will most likely say yes).

You can also find people by asking your product or service’s current users via an email blast, or by reaching out to those who have submitted a support issue.

It’s common practice for researchers to compensate interviewees, though it’s encouraged to try to compensate as little as possible. That’s why you’ll often see companies recruit by saying something like, “Talk to us for 30 minutes and get entered to win a $25 gift card.” The idea is to provide just enough compensation to entice people to participate, but not too much to introduce additional bias into the data.

If you have a large budget and are looking to speak with very targeted users, you can also hire a company to recruit users for your test. This can be very expensive and can also inject a bit of bias because those users tend to be compensated at a greater rate than willing participants from other methods. But sometimes that route is the only efficient way to get access to a specific group of people.

Depending on where your users are located, you might conduct an interview in person, on the phone, or over video conference. It’s best to have two people from your team there to conduct the interview so that one person can ask the questions and have a conversation while the other takes notes. (It’s quite difficult to simultaneously take notes and practice active listening.) If you record the interview, make sure to tell the user beforehand.

The goal of a user interview is to get at why users behave the way they do and how they feel about their experiences. Because of this, it’s important to ask open-ended questions that focus on the person’s past or current behavior. Interview prompts can even be phrased in a way that it isn’t a question, such as, “Tell me about a time that you [used a self-checkout/searched for clothes online/scheduled an appointment with a doctor],” or, “Tell me about the last time you…”

After the user has described what happened, follow up with questions that get at why they behaved or reacted the way they did. Ask them questions about how they felt. Watch their body language as they answer those questions. Sometimes the most important information about how to proceed can come from what people don’t say.

Above all, do not ask users to predict what they will do in the future. If you find yourself asking questions like “Would you use this product?” or “Would you pay for this service?” or “What would you like to see in future updates?”, simply pause, and rephrase the question so that it asks about past behavior. “Why did you use this product or similar products?” “Have you ever paid for a service like this?” “Why have you stopped using this product or similar products?” By focusing on past behavior, teams will gather information about the problems users are facing so that they can use their collective wisdom and skills to come up with innovative solutions that succeed in market.

In General Assembly’s full-time User Experience Design Immersive (UXDI), part-time User Experience Design, and part-time Product Management courses, students get firsthand practice conducting interviews. We first discuss how to interview and learn best practices for being effective. Then we jump in and start interviewing. Students draft questions and an interview script, practice with one another, and get immediate feedback from their peers. Then they set out to find and talk to real users who have the problem they’re looking to solve. In UXDI, students work with real-world clients and conduct interviews with their current or potential users.

After their first interviews, students generally say that the experience of approaching and talking to strangers was a bit scary, but also that it gave them so much good information that they need to take their projects in a whole new direction. Essentially, they discovered that their assumptions were incorrect and they now understand what problems are worth putting more time and effort into exploring and solving.

Tricia Cervenan is an instructor for General Assembly’s part-time Product Management course in Seattle. She has been developing products for over eight years and currently helps clients solve software problems at the product agency L4 Digital. You can find Tricia on Twitter at @triciacervenan.

It was a strange sight: a 40-year-old man taking a block of wood out of his shirt pocket, then pretending to scribble something on it with a stick. He stopped, then tap, tap, scribble again. After that he put it back into his shirt pocket.

The man is Jeff Hawkins, the inventor of the PalmPilot, the first handheld device that put computers into our pockets.

Hawkins had launched a similar venture a few years earlier, an amazing handheld computer called GRiDPaD. This was before we had LED monitors, when laptops weighed more than 10 pounds, so it was an impressive piece of hardware — but it was a flop because it wasn’t small enough for people to carry around. This is why he decided to simulate the experience of carrying around the device by cutting a block of wood representative of its size, sticking a piece of paper on it to simulate the interface, and carrying it around for months. Every time he needed to make an appointment, he’d take it out and pretend to check his calendar on the “device” and add the appointment to it.

This story illustrates prototyping — a quick and cheap way to simulate a product experience in order to reduce risks — very well. In the Palm Pilot example, the biggest risk was that the device might be too big to carry around. This type of prototype looks very crude because the focus is on realistic scenarios.

Prototypes can be really close to the final product with all of the features that will be included when the product is launched. But designers often start out by making a rapid prototype, the quickest and easiest way to prototype, in which the designer tries to mimic the experience without actually building or creating anything.

In software development and product design, rapid prototyping refers to techniques used to simulate the experience of using the software. In most cases, these techniques involve no coding in order to optimize speed and minimize cost. The goal is still to reduce risks — in this case, having to do with the product’s efficiency and effectiveness.

Effectiveness and efficiency are essential in user experience (UX) design. Effectiveness means the product’s user is able to get the value they come to the product for. If you’re an Airbnb user, you want to be able to book a place to stay while traveling. How do you do this? You would visit Airbnb’s website or open its mobile app. Can you accomplish this task (booking a room) using the website or app? If you can, then it’s effective — it’s giving you the result you desire.

Now, just because a product is effective doesn’t mean it’s efficient. Efficiency means you can complete the task with very little effort. If booking a room on Airbnb’s website takes you over an hour or too many steps, you probably wouldn’t use it often.

To determine whether a product is effective and efficient, we need to test it. And if the product is not built yet, we create a prototype and test it with real users.

The UX design process is based on design thinking framework, a problem-solving approach used by designers that’s centered around the target audience for which they design. It starts with understanding who they’re designing for (called a persona) and the problem the persona has before coming up with solution ideas. This way, the solution directly addresses an actual problem the target audience is experiencing.

The design thinking framework looks like this:

1. Empathize: Understand who your users are and the pain point(s) they experience.

2. Define (the problem): Using the problem as a starting point, generate ideas for potential solutions.

3. Ideation: Generate ideas and choose the one or two most promising.

4. Prototype: Create prototypes of the best idea or two.

5. Test: Test the prototypes, and use the learnings to improve the solution. After testing, you’ll return to the appropriate step. For example, if the idea is not effective, you’d go back to ideating more or simply choosing another idea to prototype, then test again.

UX designers go through this iteration loop multiple times until they find an effective and efficient solution.

The focus of prototyping is to get as much learning as possible with the least amount of effort. This means we only put into the prototype what we need to test, based on what we want to learn about our product idea. In Lean Startup, a methodology to build businesses and products, this concept is called building the minimum viable product, or MVP. The focus here is the viability of the product idea — is it going to work?

When creating prototypes for digital products, like apps and websites, there are many tools available. These tools allow designers to create prototypes, regardless of whether they know how to code. Some of the platforms commonly used by professional product and UX designers include InVision, Marvel, Flinto, UX Pin, proto.io, and Axure.

Creating a prototype with these tools is very easy. Here are the steps:

1. Use a UI design application like Sketch or Adobe Photoshop to upload screen mockups (typically in the PNG file format).

2. Add hotspots — areas with which users can interact — to a screen and define what should happen when the user interacts with it (e.g., take the user to another screen, transition between pages, etc.).

3. Preview the prototype to make sure it’s doing what you want it to do.

4. Repeat steps 2 and 3 for each screen.

Once you’ve connected all the screens, you can then use this prototype to test your design in usability test sessions. You’d show the users your prototype, then ask them to complete the specific task for which you’re designing the prototype. This would allow you to discover, then address issues that block them from completing the task.

At General Assembly, students in our full-time User Experience Design Immersive and part-time User Experience Design course (on campus and online) learn hands-on how to create a rapid prototype by using Sketch to create the screens, then InVision to connect those screens and make them interactive. This portion of the course happens right before the students learn how to conduct usability testing to make sure their design work well.

In order to determine what to prototype, students create user flows, wireframes, and information architecture before they create the screens in Sketch. By the end of the course, students have both the theory and hands-on experience of applying the design process.

Students in GA’s part-time Product Management course also learn to create rapid prototypes; after drawing drafts of their wireframes on paper, students turn to platforms like Sketch, InVision, and more to digitize their designs and create interactive prototypes.

Danny Setiawan is a UX professional with 15-plus years of experience. He is currently the managing director of CoCreate, a UX consulting firm, and a product mentor at Starta Accelerator. Danny has worked with brands like Yahoo! Finance, The Economist, PwC, MSN, Kimberly-Clark, and Microsoft. Danny teaches the part-time User Experience Design course at General Assembly’s New York campus.

When you think about the world’s most visionary leaders, whose faces do you see? Steve Jobs? Elon Musk? Perhaps Oprah Winfrey, Bill Gates, Sheryl Sandberg, Henry Ford or Amelia Earhart? In hindsight, what makes these leaders “visionary” is often the enormous degree of impact they enabled. However, leaders like the list above rarely stumble into their success; they enter their field with a resolve for how they will make a difference. They see things no one else does. They have a vision.

Seeing things no one else can see takes practice. It’s not a bolt of lightning, but consistent practice that allows truly visionary leaders to constantly push the boundaries of what products can enable a better world. Subsequently, forming a product vision enables you to set the North Star to guide you and your team toward a goal without leading you astray.

In the context of product management, business strategy, and entrepreneurship, if your company’s mission is to solve problem “X,” your vision is the imagined and idealized world in which your product has solved problem “X” with the greatest conceivable outcome. The best product visions paint a picture of a dramatically better world in which the lives of your users are improved by your product.

Having a clear product vision allows product teams and leaders to:

• Suspend constraints. It’s impossible to develop a vision without dreaming big. Thinking about the ideal end-state, even if only for a moment, will allow you to open yourself up creatively to all the possibilities of how a problem can be solved without being held back by feasibility concerns. When developing a vision, anything is plausible as long as it doesn’t violate the laws of physics.
• Inspire greatness. A well-articulated vision allows your stakeholders (both internal and external) to close their eyes and envision the same thing as you. Your customers who see themselves as part of your vision will be more likely to buy your product. Talented employees who share in your vision will be more likely to join and stay on your team.
• Set strategy. A vision helps you forge a path from where you are to where you ultimately want to be. Your vision will inform short-term roadmaps as well as long-term strategies, where you can plan concrete steps (e.g., minimum viable product, future version releases) toward your end goal, saving you time spent via trial and error iterating in the wrong direction.
• Align teams. Having a shared North Star means anyone on your team can constantly evaluate whether the work at hand gets you a step closer to the end goal, lending a level of built-in focus to your team.

A great company mission and product vision informs clear strategy and roadmaps. To clarify further, here’s an excerpt from a post I wrote about product strategy:

… I want to provide a relevant and concrete example using Tesla. I choose Tesla because a) Elon Musk is rad, b) Musk and Tesla have been unusually public and transparent about their strategy, and c) Tesla is a rare example of a company that has followed through on its strategy with execution that is down to the “T”. This puts it into a godly territory that is almost difficult to believe.

• Mission: “Tesla’s mission is to accelerate the world’s transition to sustainable transport.” (This was recently updated when Tesla merged with SolarCity.)
• Vision: To summarize, Tesla’s vision is to reduce vehicle carbon emissions through the advent of electric vehicles.
• Strategy: This is the famous “Master Plan”: 1) Build a sports car, 2) use that money to build an affordable car, 3) use that money to build an even more affordable car, 4) while doing above, also provide zero emission electric power generation options, and then finally 5) don’t tell anyone.

Interestingly, despite all of these benefits, many teams don’t (or don’t know to) explicitly define a clear product vision. Often, teams will home in on a short-term solution and begin defining, designing, and developing a product without a long-term vision. Product teams can go on for months and years building features and fixing issues based only on reacting to user or stakeholder requests without a clear end-goal in mind.
In the absence of a vision, product leaders from all backgrounds (product management, engineering, design, marketing, executives) are required to step in and define a vision and ensure that the team gets to a shared understanding.

We’ve spoken primarily about product vision at a grand level, but it can also be something as small as how a single feature can transform a user’s experience in the product. It is never too early for early- or mid-career professionals to practice developing and sharing a product vision.

In General Assembly’s part-time Product Management course, students practice developing a product vision as part of their final project. The course guides each student through the steps from identifying a problem in the market to solving that problem — no matter how small the product or feature may be — through the development of the product ideas into a concrete vision, executable roadmap, along with success metrics, and product design.

For businesses, train your team to get the full picture of the product development cycle. Through design thinking, lean methodology, and agile development skills, you can ensure your company is equipped to efficiently develop and deliver effective digital products and services.

Vince Law is a Product Management instructor at General Assembly San Francisco, where he has helped newly promoted product executives become effective leaders and aspiring product managers land jobs. He was previously GA’s director of product management, a role in which he directed, mentored, and built a team of 15-plus product managers across a spectrum of initiatives. In addition, he advises and consults various startups around the world, and blogs on Medium. He has previously served as the senior product manager at Storm8 and as a product manager at Kabam, and has worked in the consulting, finance, telecom, and automotive industries in various capacities.

By Cliff Gilley

Agile methodologies in product development are those that embrace the principles of the Manifesto for Agile Software Development, a set of guidelines created in the late 1990s by a group of software development professionals seeking to revolutionize the business. These methodologies focus on performing work in small, iterative steps that allow a product team to validate its assumptions and test hypotheses frequently. Examples of these methodologies include Scrum, Kanban, and Extreme Programming.

These Agile methodologies are often contrasted with “waterfall” approaches, which focus on defining as many of the requirements as possible before the project can begin, in as much detail as possible, so that there is no question as to what will eventually be delivered. The biggest downside of a waterfall approach is that it requires a large amount of up-front work and long development times before anything useful and testable is actually completed.

The importance of the Agile way of thinking cannot be understated in the modern business of software and general product development; its application stretches from development and quality-assurance work up into product design and management, and even into marketing and business strategy. While Agile began as a solution to a very specific set of problems developers were facing, it has grown into its own culture that permeates every aspect of modern businesses. It’s essential for any product manager to understand the fundamentals of Agile methodologies so that they can influence an organization to change for the better or engage more meaningfully with their teams on a day-to-day basis.

In practice, the most popular Agile methodology is Scrum, one of the first methodologies designed to deliver software products following Agile principles. In Scrum, the product manager creates a backlog of “user stories,” simple statements of the problem a development team is being asked to solve. Each user story gets stored in a “product backlog” that the product manager prioritizes according to business and other needs.

The development teams, usually sized between five and nine members for optimal effectiveness, look at these stories, estimate their complexity, and take some of them into a “sprint” as a commitment to deliver. A sprint is a two-to-three-week period during which teams work to deliver their commitments. During a sprint, the product manager and development teams work together to discuss, clarify, and deliver all of the previously agreed-upon stories. At the end of the sprint, each development team demonstrates to the product team and interested stakeholders what it has completed. Once the team has iterated to the point that the product team believes the work is worth sharing widely, a release can be created and push out the product updates.

There are other Agile methodologies, besides Scrum, that are important to understand given that many companies may pick and choose from one or another to build their processes. Kanban focuses on limiting works in progress, only allowing teams to take on a set number of stories or efforts at any one time, then working them through to completion before taking on more. Extreme Programming, on the other hand, is a very hands-off methodology that puts most of the power and authority on individual developers rather than taking a full-team approach. This methodology stresses that constant pairing and test cycles ensure quality outputs from the teams.

The main value of Scrum and other Agile methodologies lies in their focus on atomic units of work. The Scrum team commits to a small number of user stories for each sprint, which means that, at any time, the future work can be reprioritized, or even abandoned or added to without affecting the team’s work in progress. At the beginning of the next sprint, they look at the next set of priorities and commit to delivering another set of work. This is the opposite of “waterfall” methods, which establish a large commitment over the course of many months and apply strict processes for changing those requirements.

The other value in Scrum and Agile methodologies lies in the testing overhead required to validate the work the team completes. Because the team is delivering small sets of functionality, each of those sets can be tested during the sprint. This reduces the kind of massive, overarching integration testing required with a waterfall approach, in which everything is “done” only at the end of the entire project.

General Assembly teaches Agile methodologies as it relates to software development in our part-time Product Management course, full-time Web Development Immersive (WDI), and in workshops. We focus on the difference between the principles of Agile methods and the real-world application of those methods. Expert instructors, who have used these methodologies to help teams through Agile processes in their own careers, prepare students for the use of Agile through lectures and practical examples from their real-world experiences. In WDI, we reinforce Agile principles through lessons on user stories, pair programming, and more.

Product Management is the ultimate “jack-of-all-trades” role in a healthy organization. It’s one of the few roles where you’re likely to be needed to contribute to the success of so many other teams.

 – Cliff Gilley, Product Management Instructor, General Assembly Seattle

Product development has had many methodologies over the years. We’ve seen waterfall, XP, Kanban, Scrum, “Scrum-but,” “Scrumfall,” and so on. Each one was created to compensate for a process that worked for some, but didn’t work for others. Since developing products can be costly, particularly if the wrong product is taken to market, teams have worked to mitigate that risk by iterating on how they get from idea to finished product. One such way is the concept of “lean.”

Lean was popularized by Toyota in the 1940s in an effort to increase the quality of its products for customers, while still maintaining the efficiency of the company’s assembly line. The idea was that as it continued to optimize the process for quality, anything that was unnecessary in the process would naturally be eliminated. So, when a team utilizes a lean methodology, it is working to achieve some value, with the least amount of waste.

Lean became part of the software development lexicon thanks to entrepreneur Eric Ries, who in 2008 began teaching his own methodology to software startups. In 2011, he published the book The Lean Startup.

The Lean Startup was innovative and popular among startups because it came at a time when distributing software was no longer about spending two years developing something, packaging it in a box, and selling it on a shelf for the next four years. Since software is now easily deployed over the web, today’s teams can constantly push out new tests, ideas, and architectures that reach their entire user base in seconds.

The book’s main premise addressed this shift by introducing the “build-measure-learn” process to test a hypothesis. Essentially, you start with a problem that you think exists in the market (your hypothesis), build just enough of something for you to measure its success among customers, and use that learning to build something new, add on, or scale. Then repeat. Continue repeating this until the product has reached a steady state and proven that the product is valuable enough to users to have a team of people continue to develop it.

What’s great about the Lean Startup model is that you don’t worry about scale until scale matters. Why build for 100 million users when you haven’t even gotten one yet?

In The Lean Startup, Ries talks about several startups that had success utilizing his methods. One of those companies, Food on the Table, tested out its ideas by providing concierge meal planning for users. Rather than building software first, the founders went to grocery stores, recruited a single user, and provided meal plans to that user for several weeks. The experience allowed them to quickly and easily make changes to their feature set because they simply changed paper forms and how they provided this concierge service. After testing their new plans with a few more users, they went on to build software to reach thousands more. In 2014, Scripps Networks Interactive went on to buy the product and eventually turn it into what is now Food.com.

Not all teams are able to function in a lean environment. Some companies have a lot of necessary risk they need to mitigate that generates a need for more process, documentation, and predictability. But for those who are able to cut out unnecessary process, there are a few skills that can be beneficial.

Be comfortable with change.

Since the idea of lean is to adjust based on learning, teams can only function leanly if they aren’t married to their ideas or dogmatic in their processes. This is why lean practitioners love simple tools like whiteboards and sticky notes — what they write or draw on them only takes a few moments to create, and that content is so easy to erase or throw away that it helps keep emotional distance from the idea. That way, they can determine honestly whether they’ve proven or disproved their hypothesis.

Google has popularized the concept of design sprints by utilizing some lean techniques. In a design sprint, participants use letter-sized paper to sketch out ideas and collaborate with one another with the goal of creating a simple paper prototype (though sometimes they use software) that they can then test with users by the end of the week. Teams using design sprints allow ideas to come from all over the organization and uncover answers about product direction. In the process, many ideas are discarded, and the user feedback drives the next sprint’s work.

Communicate well, and often.

Teams that cut out documentation and processes can only be effective if they fill the void by talking to one another, either virtually, in person, or both. It’s helpful to ensure everyone is using similar definitions for words, especially jargon or acronyms, to ensure that there’s a common understanding of how the team is using those words.

Collaborators also need to talk about the things that are and aren’t working for them. To mitigate waste in the work the team is doing, the processes used will constantly need to be evaluated. The most efficient way to do that (without adding more processes) is to do quick check-ins for understanding. This cultivates an environment where colleagues are comfortable speaking up when something isn’t working.

Talk to users.

The only way the build-measure-learn feedback loop works is to put something in front of users and talk to them about what’s working and what’s not. Some might say that quantitative data is sufficient in measuring success, but that view is quite short-sighted, especially when it comes to developing new products. Quantitative data tells you there is a problem, while qualitative data tells you what that problem is and why it exists. It’s only then that teams are able to know how they should iterate on their product.

As an instructor at General Assembly, I implement lean methodologies in my classroom with each lesson. At GA, we don’t create droning two-hour lectures and then send students on their way; rather, we share many short lectures followed by monitored activities, then check in with the class to ensure students are achieving each lesson’s learning objectives. This way, we can determine who isn’t catching on to what we’re teaching and what types of teaching methods are effective for this cohort of students, and then adjust the current lesson and future lessons accordingly.

We explicitly teach lean skills and concepts during the Lean Startup section of our part-time Product Management course, for which I’m an instructor at GA’s Seattle campus. Namely, we cover hypothesis development, minimum viable products (MVPs) and experiment testing, and the build-measure-learn cycle. And we implicitly practice lean concepts in the way we quickly move from idea to testing with users, to planning future iterations. In a 10-week course, there isn’t time to worry about scale, so students get the opportunity to practice lean skills, giving them the most amount of value from the course with the least amount of waste.