Press "Enter" to skip to content

Tag: product

Why I say “V1” instead of “MVP” or “MLP”

(Note: This post applies to features as well as products, but I’m only using “product” for simplicity)

For a long time, everyone seemed to use “MVP” (Minimum Viable Product) to refer to the first version of what they’ll release as a product. “MVP” has been used in books about product management and startups, blog posts, etc. I still hear “MVP” a fair amount.

A couple of years ago, I started to hear “MLP” (Minimum Lovable Product) used by some people instead of “MVP.”

I personally like “MLP” more than “MVP” because a “lovable” product sounds more appealing and valuable than a “viable” product, but if you asked 10 people to define what an “MVP” or “MLP” is intended to represent, you’d probably hear several different answers. Most of the answers might generally point in the same direction, but there wouldn’t be alignment in the definition.

Now think about how important it is for a team within a company to be aligned on what they’re setting out to do. Whenever “MVP” or “MLP” is said within that team or company, each person hearing it might have a different mindset about that first release.

people shrugging shoulders

Is the first release meant to test a hypothesis? Is it meant to help establish a new revenue stream? Is it meant to make a specific customer happy (in the enterprise world)?

Should the first release look perfectly polished? Should it be adequately polished? Is it okay to be somewhat ugly (as long as it’s usable)?

Different people think about these things differently, even within the same team/company. This is the problem with using “MVP” or “MLP.”

Instead, I use “V1” (Version 1) to represent what will be in a first release, and I accompany that with a story and artifacts (e.g., goals, flow diagram, wireframes, a design) to provide context and details. “V1” simply means the first version, while the purpose of that first version — the goals, etc — vary from one situation to another.

V1

The same person (product manager) could take a different approach for a first release in different situations. For example:

  • Is the first release going to be a limited rollout? A full rollout? Will it only be seen by existing users? New users? Both?
  • Are the users who will see the first release in close communication with the team/company? Or is the intention to have them be on their own?
  • Can the first release include a manual process that’s not a seamless solution or fully automated (e.g., using Google Forms)? Or does it need to be seamless / automated?

There’s no one size fits all in product management. Use an approach that relies on YOUR definition, not someone else’s assumption. “V1” can help you do this.

Comments closed

Demystifying product strategy

strategy-image

Since “strategy” can mean different things in different situations, here’s a definition of how I think about it related to product management:

Finding efficient ways to achieve the company’s goals through product solutions

Another way to think about it is:

Finding ways to maximize value at minimal cost

A good product strategy can give you a leg up in a race against the clock (or the competition), and it can increase the odds of your team and company being successful.

The maximize value part

This comes down to translating company/business objectives (including key metrics / KPIs) into a product plan that helps the company achieve its goals.

Product folks are tasked with helping their company achieve its goals while also helping customers (aka, users) achieve their goals, and while also keeping their team informed, efficient, and motivated to get it all done. (Project managers or other roles in an organization can also help a lot, but these roles don’t always exist.)

Sometimes, there’s a clear path for how product work can help the company achieve its goals, such as when an integration with a partner can propel a business strategy. Other times, the team needs to explore possible solutions to meet the company’s goals, which factors in:

  • Customer needs discovery/analysis
  • Team brainstorming (including exercises such as whiteboarding/sketching)
  • Research/testing with customers

After this, solutions need to be designed, built, tested, and released.

After releasing something, it needs to be measured and potentially iterated on to build out further or to optimize.

I could write posts to cover each of these steps, but in a nutshell, this is what needs to be done in order to maximize value. Depending on timelines and resources, you might be able to skip some steps, or at least move through them faster, while still achieving the goals (and perhaps revisiting in the future for further improvement). In general, I’ve found that it’s more important to be practical with how you go about things than to try to follow a process according to every detail as it’s written in a book.

The minimal cost part

There can be several types of costs with product work, including:

  • Dollar cost – You might need to pay for a technology or service to achieve a solution, or you might need to hire people. These are straight dollar costs.
  • Time cost – It takes time from one or more team members to do anything, which can be equated to the dollars that the company spends employing those people for their time. For example, if the company spends $50 per hour on an employee, and if it’d take 10 hours for the employee to complete something, then the cost of having that employee do this work is 10 hours of time which you could equate to $500.
  • Opportunity cost – This comes down to prioritization. In general terms, if you work on Option A now, then Option B might be postponed until Option A is done. The expected gains from Option B (which could be postponed) is an opportunity cost of Option A. For example, if a $10,000 gain is expected from Option A while a $5,000 gain is expected from Option B, then you might prioritize Option A over Option B. In this case, Option A brings an opportunity cost of $5,000 (i.e., expected gain from Option B), which is generally okay because it’s less than the expected gain from Option A (i.e., $10,000).
  • Team dynamic cost – This can be harder to quantify than other costs. On a high level, if your team is happy, motivated, and efficient, they’ll be positioned to do well (assuming they’re working on the right things and helping the company succeed). The challenge is maintaining a positive environment for the teamwork, which includes communication, collaboration, celebrating wins, learning from issues, and making it clear that it’s ok to discuss struggles or suggestions for the benefit of everyone (doing sprint retrospectives is one way to facilitate this). Some situations bring more pressure than others, but always remember that you’re part of a team that comes to work every day to solve problems, so tap into that in a supportive and collaborative way.

An example of where to apply strategy

Do multiple current customers, prospective customers, current partners, or prospective partners have similar needs? If so, you might be able to leverage a new product capability that can provide value across a broad spectrum of users / entities. In other words, doing a single body of work that results in more than one win is a strategy that could be explored.

Things that can help think through strategic opportunities

1. Create a product plan (roadmap) 12 to 18 months in advance

  • Break it down by quarters (e.g., Q3 2017, Q4 2017, Q1 2018, Q2 2018, Q3 2018, Q4 2018)
  • You only need to think about high level items (i.e., a new product/app or major new capability of an existing product/app) for the periods that are between 6 and 18 months away
  • Be more detailed with items for the periods up to 6 months away
  • Keep in mind — and include an explicit note on the roadmap — that roadmaps change based on shifting priorities and new learnings (about customer needs, partnership opportunities, etc). You want the roadmap to be seen as directionally correct, but fluid based on the company’s shifting priorities (or significant shifts in what’s learned from the market, such as customers or competitors).

I’ve used a few different roadmap formats over the years and currently employ the following two for different purposes:

Template A:

(this is good for high-level discussions around significant high-level deliverables)

 

Roadmap Template A

Template B:

(this is good for mid-level discussions that gets more detailed than Template A)

Roadmap Template B

Template B also helps to facilitate update meetings with any stakeholders about progress, what’s been accomplished, if there are risks or dependencies, etc.

Beyond Template B would be a backlog that gets very granular (often tracked in software like Jira, Trello, or some other project/task management tool), which typically only needs to be reviewed with scrum team members (e.g., developers and QA).

(I’ll save for another post why it’s better to have a goal-based or theme-based roadmap than a feature-based roadmap.)

2. Meet with your company’s executive leadership team (e.g., CEO, CTO, the heads of Marketing / Sales / Business Development / Customer Experience)

The main goals are to:

  • Recalibrate on business priorities
  • Make sure that executives across the company understand what’s been happening with the product and what the vision and plans are for the future

At some companies, it’s easier said than done to get executives in a room together, so you might need to sell this kind of meeting in advance by setting expectations for what’s going to be covered and what the goals are (which should clearly sound beneficial to the company as a whole and also to each department)

Conclusion

Strategy is a skill that can be developed over time. The more you think about it, work through exercises, collaborate with others, and read about examples, the better you’ll get. Just always keep the main purpose in mind: finding efficient ways to achieve the company’s goals and finding ways to maximize value at minimal cost.

Comments closed

Why you should start with a paper wireframe

In a world that’s getting more computerized every day, it may sound a little crazy to suggest that something should be done on paper when digital solutions have been developed (e.g., Balsamiq, OmniGraffle). Digital wireframes are great. They’re easy to share with co-workers, they look professional, and they’re fun to make. While I’m a big fan, I’ve found that starting with pencil and paper, or marker and whiteboard, results in a higher quality wireframe. Here’s why:

  • It’s a quicker way to get your ideas into a form that you can look at and tweak.
  • You can easily work through different variations by erasing or crossing something out, or flipping over the paper and starting again.
  • It enables you to see an entire user flow in one view to visualize everything working together before making more detailed wireframes of each screen.
  • It’s the fastest way to get feedback from a co-worker, which could result in a quick iteration or scrapping the whole thing and starting over.

By the time you’re ready to digitize what you’ve done on paper, you will have thought through the core goal(s) that you were trying to accomplish and worked through issues that you discovered along the way. Then, you can focus on any final adjustments once its digitized before handing it off to the next person in the development process.

Example

I came up with a ‘question of the day’ app for a simple example to use here. Depending on which out of the multiple choice answers the user selects, they’d see a different result. Here’s how I sketched it on paper:

Image of a paper wireframe

It’s sloppy, but it’s a sketch (and I also have sloppy handwriting). Remember, the goal is to quickly reach a point where you can rethink the idea, or to get feedback from others, resulting in a better version.

When I was in the middle of the above sketch, I thought it’d be good to include a “change your answer” option, so I added one at the bottom right of each answer screen. Clicking on this would send the user back to the question so they could choose a different answer. I didn’t need to resize anything to fit this in — I just added it in the corner, and it’d look better in the next version of the wireframe.

When I finished the sketch, I thought it’d be good to show what other people had selected as their answers, similar to poll results. I couldn’t fit that into the answer screens that I had sketched, so I added a representation of it at the bottom right of the paper (and I would explain this to whoever I shared the sketch with). It could turn out that the poll result feature doesn’t make sense to include, or at least not in the MVP, so it could have been scrapped anyway. As long as it was sketched in some form, it was ready for a discussion or a decision.

Depending on who you work with and what they do in their job function (i.e., some designers and product managers handle different things and have different processes), you may find that all you need to do is deliver a sketch and have someone else run with it. Or you may be the person who receives a sketch and needs to make it better. Whatever the case, I’ve found that step 1 being on paper gets you there in a better way.

Subscribe to this blog and get future posts emailed to you.

Comments closed

Improving the Pocket app

This is the first of a series of posts where I’ll be looking at potential improvements to products.

Pocket is one of my favorite apps and I was recently asked what I’d improve about it. The Pocket team has done a lot of great work outside of the app, including:

  • An ease of adding content into your items list for future consumption: you can save items to Pocket via email, a bookmarklet, and hundreds of apps
  • The ability to use the app on many devices, including smartphones, tablets, computers, and even some e-readers (they’ve integrated with Kobo)

I point this attention to outside the app because the consumption experience and sharing capabilities inside the app are pretty good. There are always opportunities for tweaks and optimizations, but some higher impact changes can potentially be made in the areas of discovery and sharing when users are outside the app. I think the Pocket team knows this, as they recently began sending a weekly email to users with a few suggestions of popular items that you may be interested in.

Example of Pocket app's discovery emails

This email is aimed at increasing engagement via discovery of new content, potentially resulting in more items being added to Pocket. So now Pocket has made advancements with discovery outside the app, but what’s still missing for me is a nudge to share content more than I currently do.

I rarely share content via Pocket with others. I use the app for a few minutes at a time (such as when I’m on the subway), so my focus is on reading what I have time for and then moving onto something off my device (such as getting off the train). Sharing doesn’t need to only take place inside the app — I’d explore a way to get users to share items when they’re not using the app.

The goal here is to increase virality through users sharing items. More items shared = more potential new users of Pocket. I’d experiment here with a periodic email sent to users that nudges them to share items that they’ve already consumed. This is different from the ‘discovery’ focused email described above, as here the user is already familiar with the content (it’d be a few items they’ve consumed within the past week) and can make a quick decision to share it.

Wireframe of potential sharing email for Pocket app

  • If the user is on mobile and the Pocket app is installed on the device, tapping on a sharing icon would open the app and put the user into the app’s existing sharing mechanism to complete the share based on the selection they made in the email (e.g., tapping to share via Facebook)
  • If the user is on mobile and the Pocket app is not installed on the device, tapping on a sharing icon would open the web app in the device’s browser with the user auto-logged in and they could complete the share
  • If the user is on desktop, clicking on a sharing icon would open the web app with the user auto-logged in and they could complete the share

The best number of items to include in the email could be A/B tested, but for the sake of this post let’s go with 4. Here’s how they’d be selected:

  • If the user consumed 5 or more items during the past week that they didn’t already share, include the 4 that were most popular based on what other Pocket users have also consumed
  • If the user consumed between 1 and 4 items during the past week that they didn’t already share, include all of those items
  • If the user consumed 0 items during the past week, send the same ‘discovery’ email that Pocket currently sends (with no built-in sharing element)

In some cases a user will have only consumed articles and no videos, or vice versa, but here we’ll assume it’s both.

Depending on which metrics are most important to Pocket, the results of this new ‘sharing’ email (the goal being to increase user acquisition via some of the people who receive a shared item) could trump the results of the existing ‘discovery’ email (the goal being to increase engagement from the primary user).

One option is to combine the ‘discovery’ and ‘sharing’ emails to introduce a couple of new items to the user along with a couple of already-consumed items that they may want to share. This could be tested.

Example of potential discovery and sharing combination email for Pocket app

The following would be tracked from the emails to measure success:

  • Email open rate
  • Click-through rate on items within the email
  • Shares that originated from the email
  • New users that resulted from a share from the email

Success would primarily be determined by new users that resulted from the shares. A secondary benefit would be increased engagement by existing users who either share items or receive shared items.

Comments closed