We are back. Here’s what is UpNext.
One year. This is what we told ourselves and our respective partners. We would take one year to recharge and reset and ensure we were free of any conflicts. We owed it to them after a rollercoaster of ups and downs, of tears and triumph. As of this week, one year will have elapsed since our journey with Left Technologies came to an end, the company we co-founded and poured our hearts into for more than a decade.
Yes, we dabbled a bit here and there since last summer. We pulled together a consortium to acquire the assets of Left Technologies after its valiant struggle to survive. Once acquired, we kept monetizing, we caught our breath, and we watched the world unfold.
But now, the wait is over, it is time to soar... upwards.
We are building a decentralized travel marketplace to connect travelers to property owners and managers. This marketplace will operate under the Rent By Owner brand and be available in multiple languages and geographies around the world, operating on more than 50 unique domain names. The pandemic has highlighted how inefficient the existing travel ecosystem really is, especially in the short-term rentals market. This inefficiency manifests into higher fees absorbed by travelers, resulting in less travel being taken and less memories being made. When Left Travel becomes UpNext, we will build an efficient market in which travelers can connect directly to the property owner or manager, seamlessly transact and trust, and worry less about whether the place they book will meet expectations. Rent By Owner will be for travelers, by owners.
We believe that better memories are made when we foster better travel.
We will be talking and sharing a lot more of our vision soon and our belief in this statement, but we wanted to start here with these thoughts and this post. This blog entry will be added to a few more blog posts written over the past year (backposted to the time when they were written), as they help to paint the picture for this next chapter and the journey that has led us to create our ‘why’.. This includes:
- Hello [again] World (August 28, 2020)
- 2020 is Not the End, But the Beginning (Oct 6, 2020)
- It is Kind of Fun to Do the Impossible (Feb 26, 2021)
Being better means not settling for good enough. Being better means exceeding expectations. Better implies we can improve on the negative impacts of travel while enhancing the positive. We also believe that because travel connects us to other people, other places, and to new ideas, the world grows closer the more we interact and travel. Thus, if we can make travel more efficient, more people will be able to travel, meet new people, expand horizons, and enhance understandings. Thus, when we build a more efficient marketplace, we will create more travelers and create more memories worth sharing. This is our north star.
We are still known as Left Travel Inc formally, but we will soon be rebranded to UpNext Travel and both this current Left Travel website as well as that of Left Technologies will be pointed to this new site. We do want to keep some elements of the old Left website operational as those stories and those memories are worth holding onto, even with this new beginning. UpNext will be operating five primary brands that will evolve in the coming weeks, months, and years:
- Rent By Owner – For Travelers. By Owners. This is a more efficient marketplace for travelers to find and book short term rentals.
- Hotala – Connecting travelers, particularly those traveling internationally, with better accommodation and travel choices
- Varoom – For things to see and do on the journey itself.
- Charters – For luxury experiences, transport, and one-of-a-kind memory making
- OneDegree – We believe we can (and must) encourage the world to travel sustainably.
Just before the pandemic began, Left had been repositioned itself as a company that enabled “Travel with Purpose.” We believed then and still do today, that the best companies should be measured by not just their bottom line, but on their overall contribution to the world. The core values we espoused helped us create a new kind of company that was recognized locally, nationally, and even internationally as being “Best for the World” in how we treated our team, how we participated in the community, and how we tried to model what we wanted to see in the world. These values were inside us, and while Left itself is no longer, we will carry forward those ideals into UpNext.
After ten years, there was a lot to be proud of in that which we created. We were proud of what we had built at Left, Left Travel, and the other companies and projects we were involved with along the way. We were proud of our team, both in Canada and in Bangladesh. We were proud of the innovation and technology we had created, including our approach to data-driven marketing and our breakthroughs in mesh connectivity. We were proud of the impact we made in our community and other companies, including inspiring others to join the B Corp movement.
A year ago, we would have also said that we have a lot of regrets: regrets for projects unfinished, or objectives unmet. However, every decision made in the past has brought us to where we are today, to a place of optimism and hope for what comes next. Everyone has a choice to live in the past, to dwell on what might have been, or to look up and forward. Life is about what is up next.
In the beginning, we went left. Then we went right. But this next chapter keeps our values alive yet aligned towards a new direction.
Upwards.
John, Chris, & Rakib
2020 is Not the End But the Beginning
Hello again.
In my first post, I described my plans to be documenting our journey, our restart -- from our moment of creation, straight through to launch and beyond. Consider this your backstage pass to the creative process that is entrepreneurship, filled with a world of uncertainty and doubt along the way.
The bankruptcy of Left Technologies is now official. While I know the ending of that journey is not what any associated with the company had wanted, sometimes life is not fair. The pandemic has changed life for everyone. Offices have been shuttered (including ours); lives have been lost; education and schools have been disrupted; borders have been closed; and fear and uncertainty reign supreme.
But within this, there is hope and opportunity. Stories abound of nature healing itself. Marine life is returning to places not seen in generations, carbon emissions have dropped, and scientists are cooperating and sharing in search of solutions to a global problem. If we can fight this together, then this gives me optimism that we can tackle climate change and other ills that plague the planet.
Most of this post is going to be talking about The Great Acceleration, a concept that describes:
“The dramatic, continuous and roughly simultaneous growth rate across a large range of measures of human activity.”
We have used this concept to identify opportunities in the past, and I believe it will play a large part in this next adventure too, whatever that proves out to be. More specifically, we believe that opportunities exist at the intersections of massive global trends. Concurrent to this is our responsibility to deal with the negative consequences that emerge when these trends collide, stack, and overlap.
But before I expand on this concept, I want to share some insight into the name we likely will be using for this next chapter of our journey (assuming we can close out the acquisition of the dotcom domain, a step we feel is important to creating a globally recognized brand). I feel it is important to tie our chosen name into a post about The Great Acceleration because the name and concept are intertwined closely going forward.
We will be Varoom.
Varooooooooooom. It is fun to say whether and even more fun to imagine what we might create.
Why Varoom? For us, the name is multi-layered, and each layer should be revealed slowly, like a nice meal with friends that lasts deep into the night. Or Ogres. Or parfaits. They all have layers.
First, some additional background about myself for those who don’t know me (which is most who will be reading this). In university, I studied English and Art History. While many joked that this is a great combination of useless skills, it turns out a background in Liberal Arts became a unique combination to dabble with and create startups. My first venture was back in 1997/98, which is also where my friendship with Chris began. He and I were working on different ventures but would meet up to discuss ideas and speculate on how the Internet and our businesses were going to change the world.
When in school, I had assumed that studying English would propel me into a career, be it law or some other such recognizable field. However, I was fascinated by my Art History classes. It wasn’t, “Wow, look at that pretty painting,” but more so, “Why did the artist create a specific work at a specific time? What was socio-economic commentary that was being made? What influence did past masters have on a specific artist or work, and how did that work influence future generations?”
Personally, I did not consider myself an artist. I had met many, and I didn’t have any talent nor inclination.
It was not until many years after my studies, when well into that first start up, I realized I too was creating art. We all create art. But for me, my canvas was not acrylics, nor marble, nor music, nor charcoal. My art was the company and the ideas that propelled and willed it into existence, sometimes even into the physical manifestation of the office space or employee experience.
What I wanted to create, and the things I would want to build were to be a manifestation of the world around me, and hopefully provide commentary on the socio-economic conditions of the life that I saw. My ethos was that if we built things well, hopefully our ‘art’ would influence future generations and bring about the change we want to see in the world. As with art, only time is the judge of whether it creates this lasting mark. Many companies learned from what we created at Left and copied elements from our culture playbook, or saw that one could build a company to the benefit of all stakeholders, so this did manifest into reality.
Which brings us back to our choice for the name/brand of Varoom.
In 1963, an American painter and pop artist named Roy Lichtenstein created a work called Varoom! (and a similarly named Varoom, sans exclamation mark in 1965). While Warhol may be more well renowned today, Lichtenstein was as prodigious and has garnered as much acclaim for his pieces. The painting Varoom! was part of a collection of comic-book style paintings and onomatopoeic words on canvas that was a partial commentary on the militarization of the world. However, to best understand the piece, one has to look at what was also happening in the artist’s world at the time.
In Lichtenstein’s 1963, the world was not far removed from the Cuban Missile Crisis of late October 1962. Children would practice nuclear drills in schools. The global space race was in full swing with Kennedy having pledged to put a man on the moon by the end of the decade. Civil Rights and Gender Equality were becoming more than just topics around the evening dinner table. And technology was ramping up at what appeared, then, to be a breakneck pace.
In 1963, the world was also experiencing a global consciousness. There was a collective realization that what happened “over there” would impact life at home. A generation before, the idea of flying internationally was unfathomable. Now, PanAm and Trans-World Airlines made the dream of flying across the country, the ocean, or to the other side of the world a realistic possibility. But perhaps the most defining element of the time was the photos that emerged from space, giving the planet a collective selfie for the very first time. With the first photo, we became one.
I like to think that Lichtenstein captured all of this in Varoom! The explosion of technology; commentary on the military-industrial complex; the intersection of the common (comics) with the high-brow world of art; and the realistic and ever-present danger that too-much technological advancements, if left unchecked, could have a disastrous impact on the planet. I also like to think that by using the onomatopoeic word of varoom, his work was a commentary of the speed at which all of this was happening. Whereas paintings like Jackson Pollack were using Action Painting to capture the frenetic pace of life, Lichtenstein did it with the singular word Varoom! exploding into our consciousness.
Dr. Martin Luthor King said in his famous I Have a Dream speech that same year:
“1963 is not an end, but a beginning".
Thus, in my opinion, Lichtenstein’s Varoom! was the artistic starter’s pistol that records the beginning of The Great Acceleration.
The Great Acceleration Explained
What is The Great Acceleration and why should we care? As noted earlier, it refers to the concept that the world is experiencing roughly simultaneous growth across a large range of human activity and the resulting impact that this activity has on the planet and its systems. That which is changing (and being measured) includes:
Socioeconomic trends
- Population
- Real GDP
- Foreign direct investment
- Urban population
- Primary energy use
- Fertiliser consumption
- Large dams
- Water use
- Paper production
- Transportation
- Telecommunications
- International tourism
Earth system trends
- Carbon dioxide
- Nitrous oxide
- Methane
- Stratospheric ozone
- Surface temperature
- Ocean acidification
- Marine fish capture
- Shrimp aquaculture
- Nitrogen to coastal zone
- Tropical forest loss
- Domesticated land
- Terrestrial biosphere degradation
For the past 50-60 years, each of the above is changing and accelerating at a rapid rate: sometimes to the benefit, but often to the detriment of the planet and those of us who inhabit it.
Upon returning from our first trip to Bangladesh back in 2013, we decided that we needed to focus our company thesis on building solutions and focusing efforts on opportunities that existed at the intersections of five megatrends, each of which is closely aligned to The Great Acceleration. These megatrends remain:
- Rapid Urbanization
- Empowerment of the Individual
- Digitization of Everything
- Aging & Changing Nature of Work
- Connectivity of People & Things
For the next 7 years, Left was focused on applying technology and marketing knowhow to impact the world around us. This culminated in our efforts to address the United Nations Sustainable Development Goals (UN SDGs), which collectively gave the world the ability to measure and create targets for our impact on the people and systems being affected or in need of affectation.
In January of 2020, just before the pandemic, we announced to the world that Left’s corporate goal was to become a “Travel with Purpose” company. We believed that through travel—particularly through international travel—we could impact the UN SDGs. By enabling travel (particularly sustainable travel), the world could grow closer together, become more understanding, find ways to fight injustices and biases, and simply be better and more compassionate. We argued it would be hard to go to war with someone or commit injustices if you have broken bread with their families. Just as our lives were transformed by our first trip to Bangladesh, so too might others experience the world through the eyes of others when they travel.
Which brings us back to the name Varoom and why this brand embodies who we are and what we are trying to create.
We are living in a world of amazing transformation. Life continues to accelerate. With the positive comes the negative, and we must have a collective awareness to address these issues head on. While travel and tourism have untold benefits, over tourism has negative impacts on the world. International tourism was one of the 12 socioeconomic trends that was accelerating at an unbelievable pace. And while this pace has been momentarily slowed during the pandemic, we believe that it is not only going to come back, but it is going to come back faster and have an even greater impact on the world in the next 50 years.
So for us… ‘Va’ means ‘Go’ or ‘Goes”. We also like to think that ‘Va’ is also short for ‘vacation’, of which we all can benefit from having more of. ‘Room’ is a place where we stay and where we live. But ‘room’ is also what we want and need more.
- More Room to Stay
- More Room to Play
- More Room to Sleep
- More Room to Dream
- More Room to Work
- More Room to Relax
- More Room to Read
- More Room to Romance
- More Room to Laugh
- More Room to Explore
We have big plans for Varoom and for rebuilding the company to address problems that exist in the world. While we will recreate a lot of what we did at Left and Left Travel, we have a lot of other sub projects that will live at the intersection of the megatrends that are affecting our planet. While not all products or features will be available at launch—after all, this is not the end, but the beginning—we feel that Varoom is something that will allow us to launch and soar to new heights.
Today, Varoom is short for ‘Vacation Room’, but it also stands for fast, spacious travel to nearby places and the activities you will do during your journey. We envision making it easier for everyone to travel. We want more people to not just travel, but to travel better. We want to create a world in which everyone has more time and room to play, to relax, and to work (if you must). We want to give people the opportunity to have more room to dream, and more room to enjoy those important moments we used to take for granted.
We want Varoom to be the ideal place that works for you, your needs, and those you chose to share your time with. We know that international travel is off the agenda for most people for the near future, but we will soon be able to go further again.
We look forward to being with you on this next great adventure.
Varoom.
John, Founder
Note: This post was written in October 2020 following the bankruptcy of Left Technologies, yet not published onto this site until August 2021.
Difference Between Velocity & Capacity: A Product Manager's Perspective
Velocity
The number of story points delivered in a sprint is called Velocity.
For example, if a development team planned a sprint, and points from all of the stories was 30, but at the end of the sprint, the team delivered 27 points. The team’s velocity would be 27.
From a product manager or product owner’s perspective, this metric can we a useful tool to plan future work. From a development team’s perspective, it can be used as a KPI to monitor the health development teams.
Velocity For Future Projects
Velocity can be a helpful KPI to plan/forecast either future projects. It can also help give insight into when current projects may be completed.
If you want to do this, track the average velocity over the last 4 sprints. Using individual sprint velocity won’t work as well since single sprint velocity varies from sprint to sprint due to vacation/leave, sick days, etc. By using that past 4 sprints, it provides a better gauge of the velocity for future sprints.
For example, if the velocity for the last 4 sprints were 23, 29, 35, 24, the prediction for future sprint velocity would be 27.75 (sum((23,29,35,24)/4).
In order for this to be a meaningful tool to help your team plan future work, it’s also important that the development team can estimate both user stories and project work relatively accurately.
Remember, when using a team's velocity to plan future work, the number should be used as a guide but should not be used as a contract.
Velocity For Development Team’s ‘Health’
A ‘healthy’ development team will typically have consistent velocity sprint over sprint. This is achieved because of the team’s ability to estimate (point) work and plan sprints well (know what is realistic to complete in the sprint timeframe). Teams usually get better the longer they work together and the more consistent the type of work is.
Does having a high velocity mean the team is a good one?
I’ve been asked this a few times before, and the answer is no. Having a high velocity every sprint, or even a low velocity every sprint, doesn’t mean the team is a good or bad one.
I’d even argue that the actual number doesn’t matter. Every development team points stories differently. A 3-point user story for one team might be a 5-point user story for another. It’s more important that development teams point and complete stories consistently every sprint.
There are circumstances where consistently is really hard but we’ll get into that a bit later.
As a product manager, if you’re finding that a team’s velocity is inconsistent, it’s a good idea to diving deeper with the team and understand more information behind the numbers. Jump into the conversation with a collaborative mindset to discover more. Treat it like a user interview.
The better the development team and you get at this process of measuring output, the easier it is to collaboratively build a roadmap.
Things to understand about using velocity to track development team’s health:
- Too much focus is bad: While consistency is a sign of a “healthy/mature” development team, focusing on it isn’t always the right thing. Too much focus on consistency velocity may hinder the developer’s ability for creative problem-solving. For example, if a better idea appears mid-sprint, which is out of scope from the existing idea, you want to encourage having conversations about this. If developers feel too tied to velocity tracking, they could choose to just do the existing story because that’s what is being measured.
- Non-pointed work: In my experience, research and development (R&D, Spikes, etc.) aren’t pointed on purpose. I’ve also worked in environments where some companies pointed bugs and others didn’t. Non-pointed will lower velocity, and that’s ok. By knowing this, you’ll be able to understand that there’ll be a drop in velocity if projects need a lot of R&D. This is common in new technology projects.
- Team changes: As development teams change, this will affect velocity. Adding new team members likely won’t increase the velocity at first, it can even decrease it while the team adjusts. After new team members get up to speed, the velocity should be higher than before the addition. If it doesn’t increase, it’s a good time to dive and in and do some discovery.
- Unstable sprints: I define ‘unstable’ sprints as ones where stories are being added or removed mid-sprint. When this happens, velocity will be inconsistent.
Capacity
The total number of available hours for a sprint is called the development team’s Capacity. Available hours are calculated based on the number of available resources minus things like planned vacation/leave, company events, country holidays, etc.
Capacity is used to plan the sprint. The team commits to completing a set number of user stories/tickets within the sprint time frame. Points are used in the process to help gauge the difficulty of the story and to help gauge the feasibility of completing the sprint compared to past sprints.
For example, let’s say the team commits to 23 stories in a sprint and the point total for that sprint is 39; however in past sprints, the team’s average velocity (over the last 4 sprints) has been 27 points, the team should have a conversation why they’ve committed to more points.
If this happens, here are some things to ask/think about:
- Is our available capacity higher in this sprint? (Fewer developers on vacation, no holidays in this sprint, etc.)
- Can we outperform our average velocity? (New hires are contributing more, limited/no R&D in this sprint, last sprints had a lot of R&D, etc.)
- Are there stories that have high points which may be a risk of not completing? Can we break those down into smaller stories to reduce the risk of rollover?
Product Prioritization: Speed Boat
Identify what's slowing your product down
Welcome to 'Product Prioritization' - our series of tools, tips, and best practices for the skilled Product Manager to determine priorities and get results. Each month, we will highlight one of the dozens of popular methodologies and explain how to use it.
For our sixth installment, we take a look at a group activity called 'Speed Boat'.
Venting can be therapeutic, and it and also be incredibly insightful for your product team. There's valuable information you can take away from understanding what users or your teams hate in your product. The problem can be that complaints can in fast and furious and might not seem actionable.
It's really easy to focus on the trees instead of the forest and fix a lot of 'one-off' things for each complaint.
Early in my career, and in the early stages of a SaaS startup, if an influential user would complain, we'd rally the troops to delight them with a quick fix. Being a young company, we valued individual client satisfaction at the cost of scalability and sustainability.
It wasn't until later that I came to realize that the opportunity cost of delighting one client could sacrifice the happiness of many clients, especially when the customizations for clients meant that the product became bloated and slowed future development.
As I matured as a product manager, I was able to see complaints in perspective with the ecosystem of our product and industry. One great way to achieve this is with a prioritization technique called Speed Boat (I wish I used this back in 2008/2009).
What is Speed Boat and how does it work?
Get a group together in a room with a whiteboard. You can use a video call, but make sure you have a digital whiteboard that the group can interact with.
- Sketch a speed boat, one that looks like it should go really fast. Feel free to do this before the meeting.
- With the group, draw an anchor. Let the group know that the boat has the potential to be setting world speed records but the anchor is slowing it down.
- Explain that the anchor is a representation of a feature that is keeping your product/platform from moving faster and being better (it could be a process or service depending on your company).
Now it's time for the group's participation. Have the group draw anchors and label them with the features they feel are slowing the product down and keeping it from being great.
*Bonus points if you want to have them use size to visualize how big of a problem the feature is to them. The bigger the anchor the more the feature is slowing the product down.
If people don't like to draw, you can have post-it notes ready for them.
---
Why I like this exercise.
I've found this activity can be relaxing, therapeutic, helps with team bonding, and a visual representation of the product. Doing an activity like this also seems to take the aggressiveness/anger out of complaints.
What you'll find is that most users, no matter how many complaints they have, still want to see the product improve and your role is to tap into that.
A few tips to ensure the meeting works well and the group stays focused:
- Don't let one user command all the attention. If this starts to happen, call out other group members to participate.
- Set ground rules so the group knows it's a brainstorming session and all anchors are welcome. Details can be sorted out later.
- You can change what the boat represents depending on what you'd like to get out of your session. It may represent a product line, a website, a project, etc.
---
Thanks to Folding Burritos for creating the Periodic Table of Product Prioritization Techniques.
Product Prioritization: Planning Poker
Stop gambling on what to do next… by playing poker
Welcome to ‘Product Prioritization’ — our series of tools, tips, and best practices for the skilled Product Manager to determine priorities and get results. Each month, we will highlight one of the dozens of popular methodologies and explain how to use it.
For our fourth installment, we take a look at ‘Planning Poker’ also known as ‘Scrum Poker’.
At Left Travel, we enjoy using ‘Planning Poker’ when it’s important that the team needs to come to a consensus. This technique is perfect for:
- Aligning different stakeholders
- Extracting silo-ed information from stakeholders
- Keeping meetings interactive and fun
What is Planning Poker and how does it work?
At a high level, ‘Planning Poker’ is a prioritization technique where multiple stakeholders get together and establish the value of a project, feature, or idea. For the purpose of this blog post, we’ll discuss ideas.
The technique is gamified to estimate value. Stakeholders are presented with an idea and each one of them votes on how valuable they think the idea is by using a set range of cards or poker chips with varying values. Votes remain hidden until all members have voted to avoid influence from other members. Once everyone is decided, the votes are revealed at the same time.
After everyone has presented their votes, the stakeholders who voted with the highest and lowest values explain their reasoning. The voting process repeats until the team agrees on a value for the idea.
How to Play
Step 1: Deal Cards or Poker Chips
Each person is given a set of cards or poker chips. The value of the cards or poker chips should be set as 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. While ‘Planning Poker’ can be played with different values (like a Fibonacci sequence), what matters most is that the higher the bets get, the larger the gap is between the next lowest and next highest values.
Step 2: Rules & Establish Values
The moderator or scrum master explains the rules of the game to the group (explained in the following steps).
Next, the moderator establishes what the number value of each card or chip is worth. Since value is subjective, it is crucial to complete this step before starting the exercise. Take the time to go over a few past ideas that are complete and assign them a value. It is best to pick ideas that vary strongly in value to allow the stakeholders to be able to easily compare low, medium, and high-value past ideas to new ideas. Use the phrasing ‘X idea is a 40 because…’
Step 3: Present the Idea
Next, get the product manager or owner to present the ideas to the group and ensure that there is full clarity on every aspect of each of them. The moderator can also act as the product owner for some or all of the ideas that are being discussed. Allow time for Q&A from the stakeholders.
Tip: Standardize the way the ideas are being presented to avoid a stakeholder over- or under-emphasizing specific ideas based off of their personal opinions. Set timing and structure requirements.
Step 4: Voting
Once everyone has had a chance to ask questions about the idea, it is time to vote. Each stakeholder selects a card or chip and places it face down on each idea. The higher the value of the card or chip the more important it is to the stakeholder. Once everyone has cast their vote, all of the votes are revealed at the same time. It is important to keep the votes secret until everyone is ready in order to make sure that the stakeholders involved aren’t influenced by others in the company — no matter what their role is.
Step 5: Discussion
Start the discussion by having the stakeholders that cast the highest and lowest votes explain why they gave the idea that value. Through this discussion new data can be discovered as the high and low-value voting members will often have additional information about the idea that others didn’t have prior to voting. For example, a stakeholder might know how an idea may possibly have a massive impact on another feature, or how the idea would be a big waste of time because it doesn’t impact any key KPIs.
The moderator will typically only need to call on those who had the highest or lowest value, unless a stakeholder who voted in the middle is very passionate about an idea. At some point in the game, most stakeholders will end up on the high or low end so they’ll get the opportunity to participate. If there is someone who constantly votes in the middle, call on them at some point to make them feel included in the discussions.
Step 6: Assigning Value/Voting Again
Assuming that not everyone assigned the same value to an idea, after hosting a discussion, have the group vote again. Repeat the process until the group comes to a value consensus (they all vote the same). Once agreed upon, assign the decided value to the idea and move on to the next idea.
Tip: If the stakeholders aren’t coming to a consensus and a revote has been cast, it is helpful to ask the stakeholders that are not aligned if they are comfortable adjusting their vote up (or down) to meet with the group. This usually works.
If it doesn’t work, note down what the scores from the group were and the members who wouldn’t adjust their vote. This is done not to single them out, but to make a reminder to approach them later so that you can dive deeper into their reasoning.
Step 7: Finishing Up
Once all of the ideas have a documented assigned value, sync up with the team that estimates the size (level of effort) of ideas.
Once the size has been determined, create a ratio of the idea/ feature/ project, to the level of effort. Give bonus points if the team can take the information and get it down to story points, sprints, days, etc. Once completed, there will be a list of prioritized ideas.
Tip: A simple 4-quadrant list with value and level of effort will help identify ideas that stand out.
The Benefits of Physical vs. Software
Last week, the Left Travel team did a ‘Planning Poker’ session to value some of our upcoming data projects. When prepping for it, I looked into the benefits of using physical cards/chips compared to using a software program.
I ended up deciding to use physical cards. I found that many of the paid or free ‘Planning Poker’ software options were either too cumbersome or tied to a roadmapping system. For our team, the effort to go through the onboarding process was too much of a pain. In saying that, if you’ll be using the ‘Poker Planning’ technique often, it might be a good idea to use software.
You can purchase ‘Poker Planning’ cards on Amazon or Mountain Goat Software.
Other Uses of Poker Planning: Backlog Grooming & Remote Teams
Outside of assigning collective value, the ‘Planning Poker’ technique can be used to groom your backlog and development estimations (sizing). It is recommended to use the Fibonacci sequence instead if you’re doing one of those.
‘Planning Poker’ also works really well with remote team members. The moderator will have some extra prep to ensure that the stakeholders have the card or chips before you start (software may be a better option for remote teams), but the voting and discussions work well if everyone is on a video call.
Product Prioritization: MoSCoW
Must, Should, Could, Won’t
Welcome to ‘Product Prioritization’ — our series of tools, tips, and best practices for the skilled Product Manager to determine priorities and get results. Each month, we will highlight one of the dozens of popular methodologies and explain how to use it.
For our fifth installment, we take a look at ‘MoSCoW’, a quick way to identify things that will surface to the top and sink to the bottom. The MoSCoW prioritization technique isn’t as refreshing as a Moscow Mule but, it’s still a good one.
It’s similar to the Stacked Ranking technique, but sometimes it’s either too hard or takes too long to get a ranking of the features you want to prioritize. If you find that features are too similar, and your team is ‘arguing’ over a feature that should be in the #3 or #4 spot, MoSCoW should be a good fit.
Besides a yummy drink… what is MoSCoW?
MoSCoW is an acronym to help you remember four different categories when you’re running a prioritization session.
- M = Must Have. Critical features that must be included in the product. If it’s not included, the product release will be a failure.
- S= Should Have. Important features, but not critical for the product. These could be features released in phase 2 or added into phase 1 if your team has extra development time.
- C = Could Have. Commonly called ‘Nice to haves’ aka ‘NTH.’ These features aren’t necessary for the release. As new information comes from users, these features may move to a ‘Must’ or ‘Should’, or to a ‘Won’t’ in future planning sessions.
- W = Won’t Have. Kill these ones. These features will be things that aren’t aligned with the goal of the product, or maybe the risk/value is in the wrong quadrant.
Wait. What about the two Os?! They don’t stand for anything but are just there to create a name that’s more memorable.
This is a good method when you need a quick ranking to start to paint the picture of what should be in the next release, in the MVP, or even in the next sprint.
I’ve found that MoSCoW works better in smaller groups. In larger groups, the nuance of a feature being in the ‘Should’ or ‘Could’ group may take away from the intention of getting a quick prioritized list.
Moderator Tips
This method is also enhanced when combining it with real Moscow Mules.
When coaching a team about this method, it’s a great idea to bring in real Moscow Mule cup as a visual aid. Having this visual helps your team remember this technique.
Product Prioritization: Buy-a-Feature
Using cash to identify key ideas
Welcome to ‘Product Prioritization’ — our series of tools, tips, and best practices for the skilled Product Manager to determine priorities and get results. Each month, we will highlight one of the dozens of popular methodologies and explain how to use it.
For our third installment, we take a look at ‘Buy-a-Feature.’
At Left Travel, we enjoy using the ‘Buy-a-Feature’ technique when working with internal teams or external users who ‘want it all.’ It’s always challenging working with stakeholders who want all of the features, all at the same time — this prioritization technique helps enable them to describe the value they see in the features in a new way.
What is ‘Buy-a-Feature’?
‘Buy-a-feature’ is a product prioritization technique used when a product is under development to quantifiably estimate how valuable a feature or an idea is. To do so, a product team will work directly with customers and key stakeholders to solicit feedback and prioritize enhancements or features which the participants want or value most.
How to use ‘Buy-a-Feature.’
Our team loves this prioritization technique, and as such, we highly recommend it under the right circumstances, such as during an in-person focus group. To use it, we’ve developed a game that breaks it into 5 simple steps:
Step 1: Make a feature list.
As a team, make a list of the features that need to be prioritized.
Step 1.5: *Optional* Assign each feature a price.
Give each feature on the list a value or price. The value or price should be based on the relative size, LOE, and scope of the project to represent the effort required to build it.
At Left, we’ve run this technique with and without prices. While both options work well, we’ve found that by having prices it helps focus groups that are outside of software development understand the actual ‘cost’ of a project.
Step 2: Get customers and stakeholders together.
Get your company’s stakeholders and/ or customers into a room (or on a video call) to start the game. Explain the features on your list to the group to ensure everyone has full clarity on their benefits.
Step 3: Give out the cash.
Give everyone in the focus group the same amount of money to use during the game. If you’ve assigned prices to the features as in Step 1.5, give them between 50–60% of the total cost of all of the listed features. This is to make sure they are being selective in their buying decisions.
Step 4: Have them buy.
Ask your stakeholders to “buy” the features they like. They can spend all their money on one or two, or spread it out evenly — it’s their “money,” they can spend it how they want to!
Observe the buying process and have the stakeholders explain why they spent money on the features that they picked. This is the Product Manager’s opportunity to listen to your customers and/ or stakeholders and understand both their individual and group ‘buying’ decisions.
Step 5: Collect observations for action.
Arrange the list of features by order of how much was spent on each feature (top=most money; bottom=least money). Now you have a list of features ranked and a value assigned to them.
Once the game is completed, use the ranked list and collected observations to make informed decisions on future product development based off of your customers’ and stakeholders’ needs.
Tips when using Buy-a-Feature:
- This technique carries more weight when done with end-users as it shows the value they see in the features they would use in the product.
This game can be run either individually with a stakeholder, or in a group of stakeholders. - If there are a few features that are bought with a similar amount of money, group them together. For example, a $5 difference between two features may be insignificant or subjective to the particular stakeholder, depending on how much money you gave the group.
- Allow ideas to flow from your participants. If new features or ideas come up, use the structure of the game to ask what the estimated value of the feature would be and where it would fit within the ranked list.
- For a fun twist, use real money. There’s something about handling real money that changes people’s buying behaviour.
Product Prioritization: Feature Buckets
Using buckets to plan for future work
Welcome to ‘Product Prioritization’ — our series of tools, tips, and best practices for the skilled Product Manager to determine priorities and get results. Each month, we will highlight one of the dozens of popular methodologies and explain how to use it.
For our first installment, we take a look at Feature Buckets, originally proposed by Adam Nash.
At Left Travel, we use Feature Buckets to ensure our roadmap is balanced between:
- generating revenue
- ensuring our users are delighted
- fitting in longer-term strategic projects.
What are Feature Buckets?
Feature buckets are the classification framework of creating different groups, or ‘buckets’, that product features or ideas fit into. It is beneficial as in the way of roadmapping, and by having several buckets, it allows for a well-rounded and balanced product which satisfies more stakeholders.
The four categories of feature buckets
There are four commonly used categories used to provide balanced software. They are:
- Metric Movers
- Customer Requests
- Customer Delight
- Strategic
Metrics Movers
This bucket includes the features needed to move the needle on key metrics that matter to your business around growth, engagement and revenue. This can be anything from ARR, Churn, ARPU, MAU, LTV, ATV, etc.). For example, at Left Travel, we use metrics that focus on the traffic we send over to our partners and the quality of that traffic. For this, we use Qualified Referral Rate (QRR), Revenue Per Qualified Referral (RPQR), and our partner’s Conversion Rate.
If there is alignment on what the key metrics are that your business follows, it helps narrow the scope of this feature bucket.
Customer Requests
The Customer Requests bucket is filled with requests your organization receives from users and is important to carve out your roadmap. While having this bucket doesn’t necessarily mean you’ll address all, or even a large portion, of the requests that come in it, it does help ground the company to identify current pain points that users are having and decide when, how, or even if, you will address them.
Customer Delight
Remember the time you showed a user something, and they LOVED it? Features in this bucket may not be coming from users directly, but they spark joy in the customer when they see it. Here’s the best recipe to craft these features into delicious user treats:
- Listen to users and understand their pain points.
- Leverage technology to test and try.
- Innovate on UX to deliver and delight.
Strategic
Data projects and new markets or opportunities are types of projects that can be hard to fit into the three previous buckets but are still important. That is why there is the ‘Strategic’ bucket for features that help keep the software looking forward and past some minutiae. Use this bucket to think big and be aligned with the business’s values and goals.
Balancing Buckets
Having not enough buckets
Having too few, or too many, buckets can cause problems.
If you have too few buckets, you may be putting all your eggs in one or two baskets. For example, if you only worked on features that fit into the Metric Movers and Customer Requests buckets, it is easy for your roadmap to lose sight of the bigger picture. If this happens, your software may become bloated with customer requests. This often leads to making segments of your customers happy for the short term while making the software more complex for the rest of your users. If you don’t have work filling up each of the four buckets, you’re missing important feedback opportunities from either internal or external stakeholders; or simply put, there’s a blind spot in your software.
How to find your Feature Bucket blind spots
- Brainstorm what features fit into the empty bucket(s).
- Imagine a competitor. How would their product stack up against yours? Focus on that.
- Take the list of features you’re not building and run them by your stakeholders (users, developers, dev ops, support, executives, sales, marketing, etc.,). What is their reaction?
Having Too Many Buckets
Simplicity is important when you need to be constantly communicating the roadmap to stakeholders. With too many buckets, it can get confusing. If you have lots of feature buckets, it’s time to think long and hard about why the extra buckets exist. Ask yourself the following questions:
- Was it created to get a stakeholder’s work on the roadmap?
- Could the buckets be rolled up into fewer ones?
- Are the buckets too granular?
An important part of a roadmap is to be able to effectively communicate what’s happening now and what will be happening soon. If you have 8 buckets, it’s hard to have your team understand and support all of them. Best practices show that people can hold between 3 to 5 buckets effectively.
Ok… where does prioritization come in?
The feature bucket technique is aimed at exposing and categorizing ideas or product features into groupings. When I started at Left Travel, I found that the customer request and customer delight categories were under serviced. By ensuring that we keep our focus on those areas, we’ve been able to further close the gap between our competition’s user experience. Using feature buckets, it should help to:
- expose which buckets have too many or too few projects — helps to identify blind spots
- identify which features or ideas don’t fit into your roadmap and can be removed
- enable a meaningful conversation about the capacity assignment for each bucket and your team.
NOTE: This technique is not helpful to determine which feature is more valuable to do first.
Roadmap Example
Below is an example roadmap which visually resembles buckets (rows) and their status (columns). This can be easily changed to show dates in the rows if that’s the type of roadmap your team prefers.
Product Prioritization: Stacked Ranking
Using rankings to facilitate discussions
Welcome to ‘Product Prioritization’ — our series of tools, tips, and best practices for the skilled Product Manager to determine priorities and get results. Each month, we will highlight one of the dozens of popular methodologies and explain how to use it.
For our second installment, we take a look at stacked ranking, first popularized by Jack Welch at GE in the 1980’s.
At Left Travel, we use stacked ranking when our team is looking for a quick and dirty list of priorities. Whether it’s a list of high-level sprint goals or which beer to buy for beer-o-clock, we’ve found this works best if the items in the list aren’t too complex.
What is stacked ranking?
A widely used prioritization technique, stacked ranking is used across multiple industries. At its most basic level, stacked ranking is the act of taking your list of items (ideas, stories, epics, etc.) that needs prioritization and ranking them from the most important (top of the stack) to the least important (bottom of the stack). That’s it — easy right?
The answer is yes and no. While the prioritization technique is simple in practice, it relies on qualitative data and opinions, which may not align with user value.
Tips and Tricks
1. Question the order:
Whether you created the list, or you’re reviewing it, it is important to ask questions about the reasoning behind the order of items to avoid bias.
Questions to consider:
- Why is the top idea the most important?
- Why is the bottom idea the least important?
- How much more/ less important is the idea in the middle than the top/bottom idea?
2. Rank individually, discuss together:
To avoid opinions being swayed during your team’s initial stacked ranking process, have each team member rank the list on their own and then compare the results. When there are differences between the lists, encourage a discussion to discover why.
At Left Travel this has led to great collaboration and knowledge sharing, particularly when someone on our team specializes in a certain data set.
By using stacked ranking, team members feel empowered to give their opinions on the ordering. When the team comes together, it makes for an insightful conversation about why there are differences between everyone’s ranks.
3. Get feedback:
Due to the opinion based nature of stacked ranking, it is important to solicit feedback from a wider group than your immediate team. Try circulating the list to other internal peers and stakeholders and ask if they feel differently about the ranking. Driving discussion is a quick way to get feedback and help mitigate opinion bias.
4. Individual use:
Stack ranking is great for prioritizing individual daily tasks that feed up into your larger company objectives. Online product management tools like Trello and Asana are helpful platforms to share your individual task list with your team.