Better Tech Dev

Insights on Technology Development from Austin Higgins

Category: Product Development

3 Things We Can Learn from MoviePass

MoviePass is in trouble – again. The company has been around since 2011 but came in to the main public eye sometime in 2017 with its too-good-to-be-true promise of unlimited movie tickets for $9.95 per month.

This business comes at an interesting time. In 2017, domestic box office ticket sales hit a 25 year low. And just this past month, a new theater opened up near me with tickets priced at $19 and some change. Average ticket prices have gone up somewhere around 25-30% in the last 10 years as attendance has fallen.

MoviePass offers customers one free movie per day. The process to get the ticket is entirely too complicated. Customers receive a prepaid debit card in the mail after they subscribe. Then, they can select a movie from select theaters when they are within a certain proximity of the theater. The cost of the ticket is loaded on the debit card and the customer can go the theater and get the ticket.

Critics, investors and theaters have spoken out about the business model. The company has been hemorrhaging money and has had to raise additional capital just to stay afloat. The executive team considered raising the monthly price for their 3 million customers but instead opted to lower the number of movies customers can see from one per day to three per month.

I can’t imagine the 3 million customers will stay for long. Or that the business will survive without major changes.

As a fan of the cinema, I considered subscribing to the service. I decided against it for a number of reasons and chose to watch the company’s story unfold from afar.

Here are a few lessons we can learn from MoviePass.

1. Build easy to use products. 

The process for customers to use the service is cumbersome. A customer can’t just buy a ticket on their phone and go on with their life. They have to take 3 additional steps – including a geo-located one – just to use the service.

Customers would be better served with an easy flow and simple steps. A simple solution is an elegant solution.

When you are designing products and features for customers, focus on usability. Not just from a design standpoint but from a process flow standpoint. This may sound like it is common sense. But obviously, it is not taken seriously everywhere.

2. Don’t alienate your suppliers. 

MoviePass faced tough criticism from major theater chains like AMC during their pilot program in San Francisco as well as after the nation-wide launch. Theaters wan’t more than just ticket sales – they want to know why you are purchasing and to build a longer-term customer relationship so they can provide better experiences, ancillary sales and promotional items based on relevant data.

MoviePass cannot exist without major theater chains. Alienating and competing with your suppliers is not a good business model.

Look at the end to end value chain and supply chain for your products. Who are your partners, suppliers, vendors and impacted organizations? Competition is healthy and encouraged. But where are you alienating key partners that you cannot replace elsewhere?

3. Save the best for last. 

Anytime a company raises prices or lowers value is not a good sign for customers. Had MoviePass started with one movie per week for $9.95 per month would have been an amazing deal. If they gradually increased the number of movies, customers would have received more value the longer they were with MoviePass.

Unlimited sounds better as a marketing ploy, but if its not scalable it is really just a lie.

When planning a long-term roadmap for a product, are you increasing value to your customers, keeping the same value or (gasp) reducing value for your customers? One of these is correct. One is tolerable. One is a cardinal sin.

Coffee Holds the Answer to Your Product Questions

The average consumer has no real interest in products. Features, competitive advantage, price points, usability and delivery are all meaningless to them. When a customer is making a purchase decision they are really hiring someone or something to do a job for them. This applies in virtually every industry and product vertigal. Customers hire products, they don’t buy them.

The Job-to-be-Done framework was pioneered by Harvard Business School professor Clayton Christensen. But still, most product leaders don’t realize the motivation behind customer purchase decisions.

Why People Hire Coffee

Coffee is an almost perfect way to explain the job to be done framework. Coffee is one of the oldest beverages, consumed by most people in the world today. Yet the way it’s consumed and the reasons vary more than just how many sugars.

Coffee can have many features, competitive advantages or delivery mechanisms. Coffee can be high quality or low quality. It can be sweet or bitter. It can be cheap or expensive. It can be instant or scientifically crafted. To make it more complicated, each feature is on a sliding spectrum. There can be near infinite types of coffee.

As a product leader, how can you decide what features to focus on when developing your product? You must first consider the job for which your customers are hiring coffee.

Three People. Three Cups of Coffee.

Some people choose not to make coffee at home. Their reason for consuming coffee is really to create a break in the day. To go to a coffee shop sit and read a book or otherwise checkout for a bit. He really doesn’t care that much about cost, convenience of time, because he’s after the experience not the consumption.  

A lot of people have a deep love of coffee. They may buys high-quality beans to grinds for each brew brew. They likely own a few brewing mechanisms and can make coffee in nearly every possible way. For this person quality is important but the focus is on controlling the experience.

Many people don’t care about the coffee experience and treat coffee like a utility. Make it  quickly, drink it fast get the caffeine fix, rinse and repeat as needed for fuel each day. Instant coffee and fast-brew machines solve this need.    

What You Can Do Right Now

There are a few practical steps you can take as a product leader. Realize that customer segments and demographic data is one-dimensional. Seeing your customers as a “tribe” isn’t necessarily actionable.

  1. Define your customers by job requirements
  2. Understand the motivation behind the job requirements
  3. Create hire-able and sellable solutions to these job requirements
  4. Demonstrate the solutions in a way that fits their requirements

It takes time, thought-process and energy in the beginning to do this right. If you aren’t solving challenges for your customers, what is the point?

Practical Business Value by Austin Higgins

Most organizations use bloated methods to prioritize products and features of tech products. They spend weeks (and sometimes months) trying to come up with the perfect formula to determine what they should spend their time on.

Resource allocation is important. But at some point, too much analysis and debate ends up hurting the organization in the long run. There is no way to have a perfect answer or a perfect ranking of product features.

Pragmatism is important. Is it better to do the “right” thing or the actionable thing? Most of the time, it is better to be actionable.

This is why I focus on real, quantifiable business measures of success to prioritize products in a method I call Practical Business Value. Marketing and tech leaders should only focus on 3 key categories:

  • What do customers want?
  • What is the real, financial value?
  • What are the technical dependencies?

That is it.

Don’t reinvent the wheel and don’t turn every decision in to a science project. Understand what your customers want and need from you, determine what is technically possible and technically advisable and factor in the cost and benefit. Use effective financial metrics like breakeven and return on investment.

Then get to work.

The Importance of Hyperfocus

We’ve all seen it before. Requirements, documentation and designs are behind schedule. It takes weeks – or sometimes months – for teams to put together exactly what they have been working on. You need development to start to meet specific timelines, but the teams haven’t delivered.

What went wrong?

Probably nothing. There are competing priorities for people’s time. Status meetings, standups, governance, other projects and normal distractions of the office place get in the way. These aren’t excuses, just reasons why teams don’t deliver on time.

Is there a better way? Teams that hyperfocus on tasks – especially requirements – have a higher chance of succeeding: not just on time but ahead of schedule.

When I was consulting for a Fortune 100 client, the team I was working with kept seeing delays in business, UX and technical requirements. Based on certain estimates, it could take months just to define a mid-size project. I thought it was absurd! It turned out, teams were pulled in too many directions and weren’t focused.

We came up with a solution that has morphed in to Hyperfocused Product Requirements. The framework is simple: gather the right people, follow a strict timetable and deploy a flexible framework.

Get the business lead, a technical architect and some designers and analysts in a room together. Make sure these people have the ability and authority to make actual decisions. They shouldn’t have to go back and discuss with a steering group, 3 status meetings and a committee to decide on a user flow.

Timebox each activity so that everyone stays on task. Schedule in breaks and table anything that does not explicitly help reach the goal. Determine a level of detail and quality you are comfortable with before the session starts.

Start with a few questions: In 10 words or less, what are we building? What will this product do? How will customers benefit from this? In what ways will they realize the benefit? Then list out each step, task or feature of each answer. You can use classic requirements templates like “As a x, I must/should/would like to y so that I can z”.

Won’t this take time away from status meetings, updates, standups, governance and other projects? Yes. That is the point. If you get the right people together with a task, deadline and framework you will absolutely accomplish what you set out to accomplish.

The goal is to produce good work, not make excuses.

5 Questions for Product Design

It is too easy for executives to say “I don’t know where to start” when defining new requirements for a product. The truth is, product requirements should be one of the simplest procecesses about building a new product.

Most of the time the requirements process is inconsistent across industries, departments and teams – even when building the same type of product. The methodology doesn’t impact the overall success of the product if you do not start with the right questions.

Any leader can take a small block of time and work through the following questions.

1. In 10 words or less what problem am I trying to solve?
2. in 10 words or less what am I trying to build?
3. in 3 sentences or less what does this product do?
4. In a list form, what benefit will users have from this product?
5. in 10 words or less, how will users realize each benefit?

Requirements should not be complicated. Any person with any background can get started in creating new technology products or enhancing existing ones.

What Technologists Can Learn from Stoicism

The Stoics are known for their control of their emotions and for their pursuit of wisdom, truth and perseverance. After 2,000 years, the philosophy of Seneca, Marcus Aurelius and Epictetus still hold true. This is because Stoicism is practical in nature. While I find the history and inner workings of philosophy interesting, most do not. Stoicism is popular for a number of reasons. It is practical and not just conceptual.

The writings of the ancient philosophers focus on real-world tips and tools to apply Stoicism in your daily life. This is why people, like Tim Ferris, choose to use philosophy as a personal operating system. Technologists should use this 2,000 year old method to identify what matters and focus solely on those things. Here are four things Stoicism can teach us.

1. Your product must serve a real, identifiable problem.

A product must serve a problem that a customer has and is willing to pay for a solution. The problem must be real enough to cause customers to change. Seneca talks about life being similar to a play but the importance is “not the length, but the excellence of the acting that matters.”

The same goes for everything about your product, operations and business. The excellence of delivery is the only thing that matters. And it all starts with one thing — a problem worth solving.

The first step is to have a real problem to solve. But that isn’t the only thing that matters. You must have a clear reason why you are solving this problem. The cliche and often overused words by Seneca apply here: if one does not know to which port one is sailing, no wind is favorable.

The “why” not only drives your development process, go-to-market strategy and tactics but it influences team dynamics and hiring decisions. It has been written before, but you must know your why.

2. Focus on your minimally viable segment.

If you ask technology strategists how to launch a product they will come back with a number of buzzwords and phrases. Start lean. Be agile. Build an MVP. Launch a beta. Sure, this is fine advice. But often an important piece is missing.

“To be everywhere is to be nowhere.” Seneca wrote this words to help his students uncover the importance of mindfulness and focus. This applies even more so when selecting a first group of customers to tackle. The technologist should think in this way. To try to serve every one is to try to serve no one.

Identify your first core group of users and solve their problem first. They will be your early adopters and referrers and provide early feedback on how to grow your product.

3. Data and customers are your true north.

Marcus Aurelius wrote a daily meditation while running his military campaigns. He journaled frequently on topics of perseverance and wisdom.

“If someone is able to show me that what I think or do is not right, I will happily change, for I seek the truth, by which no one was ever truly harmed. It is the person who continues in his self-deception and ignorance who is harmed.” — Marcus Aurelius

Marcus Aurelius sought truth, the best technologists can find is data. You cannot ignore data as a technologist. All aspects of data are important but some are more important than others. Usability labs, traffic, customer behavior, feedback forms and digital metrics are just the beginning. When you encounter information on how your customers behave and what they want, you must adapt your strategy and tactics.

4. Anyone on your team can add value to your product.

Every team has a leader and every company a CEO. But, team members at every level could provide value to your product. Data scientists, software engineers, UX architects and product managers all have their relative expertise. Do not discount the potential for an intern or your CFO to provide excellent input and insight on features to build next.

Seneca the Younger in his Letters to a Stoic echoed this sentiment in his writings “I shall never be ashamed of citing a bad author if the line is good.” He was referencing ethics, reason, and good and evil, but the concept applies to product management. CFOs and interns can have great UX ideas.

Enterprise Applications of Blockchain

Many business leaders still don’t have a strong grasp on what blockchain can do for their company. Most of the focus is on cryptocurrency – which is exciting but has limited applications for enterprise in the near future. The real innovations and potential with blockchain remains untapped.

In this presentation, I dispell some of the myths around blockchain, give a business-level overview of how the technology works, provide enterprise use cases, show how companies can monetize blockchain and share what business leaders should be doing right now with blockchain.

How do you see your organization utilizing blockchain?

Blockchain Simplified

I regularly hear people talk about blockchain, bitcoin and distributed databases in the business and investment community. Cybersecurity is becoming more important by the day and business leaders are trying to find ways to optimize their technology work. So, I’m not suprised when someone tells me that they must get blockchain or do blockchain.

After a number of these conversations, I started to realize that most people get one thing fundamentally wrong with blockchain. Blockchain isn’t something you do.

The origins

Many people know the story of bitcoin and its rise to financial dominance. Few people know exactly why blockchain needed to be created, though. The problem with bitcoin and non-traditional financial transactions is there needed to be a factor of trust between two parties.

In our current financial system, banks act as the keeper of all records and therefore agents of trust. If I were to send someone money from my account, how can the recipient be sure that I didn’t already spend the money? In today’s environment, the bank ensures I do not overdraw or double-pay someone.

The creator of bitcoin needed a mechanism to ensure trust between two anonymous parties. The goal of blockchain was to replace the responsibility of the bank. Because there was no centralized ledger of transactions, he created a method to tie each transaction to the previous transaction. This is a chain of transactions, or blocks.

This chain of transactions is distributed across many computers and is used as a form of authentication. If a transaction doesn’t match the the chain of transactions, it likely isn’t valid and will not be added to the chain.

Blockchain validates bitcoin transactions and stores these transactions across a number of hard drives so the likelihood of a breach of trust is virtually zero.

Google vs. Microsoft

To get a better understanding of how blockchain compares to a standard bank, compare Google Sheets to Microsoft Excel. They are both similar software with similar functions and uses. A main difference between the two is how you send and receive updates when collaborating with someone.

Traditionally with Microsoft Excel you must make your updates, save it and then send it to someone else for them to make updates. Then, you have to wait for it to be sent back. Only one person can edit this file at one time. You are reliant on a some sort of version control to know which is the most accurate version.

This is how banks operate with traditional transaction environments. Only one person can access funds at a time. You initiate a transaction, then wait.

With Google Sheets multiple people have access to the same single version at the same time. They can view and edit the document without sending it back and forth. Version control isn’t needed because it is a main component of how the software functions.

Blockchain uses distributed, linked ledgers as a way to eliminate version control from banks or any other intermediately. While Google Sheets does not run on blockchain, the analogy is useful. The purpose and general functions of Google Sheets and Microsoft Excel are the same. The main difference is in how it accomplishes the general functions.

How, not what.

Blockchain is a method to ensure integrity of transactions between two parties. It isn’t just a peer-to-peer network or distributed network. It also isn’t just a ledger of accounts. Blockchain is a system to fulfill the responsibilities of a centralized, authorization organization in a distributed, anonymous and secure manner.

Blockchain has been used outside of bitcoin and currency for some time. Music companies like PledgeMusic are using blockchain technology to ensure artists are paid when fans listen to or download their music. Blockchain is used as the intermediary. AScribe is a service for artists to sell their work online and protect against copyright infringement.

Like the Google Docs analog and bitcoin, these two companies are using blockchain in how they conduct business not as what they do. Blockchain isn’t something you do, it is a way you conduct the technology side of your business. So, when someone says they need to adopt blockchain or “do” blockchain, they must clarify exactly the goal they are trying to accomplish.

A Logical Approach to Creating New Products

Most people think coming up with new product ideas is meant for only a select few. You have to be a visionary, a genius or special in some way. This thinking is counterproductive to most people. In reality, just about anyone can come up with new product ideas.

There is a simple and scalable process for new product ideation called Systematic Product Ideation.

In the most basic way possible, new product ideation fits in to one of two categories: problem solving or growth.

You may be trying to solve a discreet and identifiable problem. An easy example is a seatbelt, helmet or most safety equipment. Or, you may be coming up with a new feature or use that did not exist before. A simple example is a smart phone or 90% of the technology you use on a consistent basis.

There are really only two ways you can come up with new product ideas, too. You either do it on purpose or you do it by accident. Another way to think of this is you come up with ideas either by feeling or by thinking.

You have 4 real categories of ideation:

  1. On Purpose and Thinking
  2. On Purpose and Feeling
  3. Accidental and Thinking
  4. Accidental and Feeling

Your brain has two main modes of thought: focus and diffuse thinking. When you are actively trying to solve a problem, read a book, learn something new, engage with a new person, you are more than likely using the focus mode of thinking. Thoughts are linear and connected. This thought method is perfect for deliberate ideation.

Deliberate Ideation

When you start out on an effort to create new product ideas, you can choose to focus deliberately and guide yourself through a number of questions:

  • What do our customers complain about?
  • What do our customers ask for?
  • What isn’t working in our product today?
  • What are customers using our product for that we did not intend?
  • What other products are our customers using with our product?
  • What are the physical limits of our product?

In this way, you are using the thought process called focused thinking. This is straight forward and obvious.

Accidental Ideation

But what about the other method, diffuse thinking? Diffuse thinking is where your mind and thought process wanders. Your thoughts are not necessarily connected and often non-linear. This happens frequently when you are engaged in a repetitive, low cognitive load task. Where does your mind go when you are doing the dishes or running? What do you think about on long, silent walks? Your mind can shift in and out of diffuse thinking just before sleep, as well.

You can prime your mind for diffuse thinking. Many great minds have used diffuse thinking to expand their thought process and come up with new ideas.

Salvador Dali was known for using a technique to open his mind to diffuse thinking. He would use focused thinking when looking for new ideas for his art. Then he would become tired and sit in a chair while holding a key. His mind would slowly shift to diffuse thinking and drift to sleep. As he fell asleep the key in his hand would fall to the floor instantly waking him and taking him out of diffuse thinking and back into focused thinking. He used this exact technique to come up with one of his more famous pieces of work — “The Persistence of Memory”.

So, what does this have to do with product ideation?

You can use either thought process to come up with problems to solve or areas of growth for your products and customers. Choose the right process for the situation at hand. Focused, deliberate discussion and thinking has its place in ideation. But do not forget to let your mind — or your team’s mind — wander while focused on other tasks.

Or just grab a key and take a nap. That works just fine, too.

Powered by WordPress & Theme by Anders Norén