Better Tech Dev

Insights on Technology Development from Austin Higgins

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?

A Better Status Report

I’m pretty confident that no one actually reads status reports on active projects. In the rare case someone actually takes the time to read them, they glance over the bullet points and store the physical (or digital) report in a folder – or more likely the trash can. They never look at them again. Or think about them. Or even want to think about them.
 
Many organizations opt for status presentations. Which by most people’s definitions are a waste of time. Why must I read the info on the report to you? Can’t you just read it yourself?  
 
While in-person meetings have the potential to boost compliance of reading or listening to a status report, there is another option. Meetings are superfluous and no one will take the time to read a status report. 
 
Perhaps people will listen to a status report instead? 
 
A 2016 Yale School of Management study found people can assess others’ emotions most accurately when communicating solely via voice—far better than written or computer-spoken words, and even better than video chatting. And if you’re in it for the speed alone, you can probably speak twice as fast as you can type. (Pierce, David. “Phone Calls Are Dead. Voice Chat Is the Future.” Wall Street Journal. https://www.wsj.com/articles/phone-calls-are-dead-voice-chat-is-the-future-1531051200. 8 July 2018.)
 
Consider this:
 
  • Project leads create their standard status report that is stored in a shared repository like Box, SharePoint, Dropbox or a shared folder. 
  • Project leads record a 1-2 minute audio (or video) recording going over an executive-level summary, the key highlights of the project, upcoming milestones and any pertinent issues.
  • The recording is stored in the same repository. Business and technology leaders can simply listen to the short recording and go about their day.
  • No unnecessary meetings. Communication improves with voice instead of just reading a stale template. 
 
The technology exists to do this right this moment. Every smart phone in existence can record audio. Project leads are accustomed to giving updates on the state of their projects – the good ones can do it in under a minute. It is just a matter of changing perceptions and procedures.
 
The only downside of shifting to a voice-based status report is the discomfort of change. But business, technology and process always changes. The question is, will you control the change or will the change control you?

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?

Stop Sending Surveys

Over the last few weeks I have received a handful of surveys to fill out. I’ve asked for feedback in the past, so I usually try to provide when it is asked of me. Every survey I have looked at has a couple of dozen questions, most of which have grid after grid of radials.

I never make it past the first page. This is especially true when I see the survey has 5 or more pages. I haven’t finished a single survey yet. And I’m one of the few people that actually want to give real, constructive feedback.

Surveys only need 2 questions.

  1. Do you like our product? Yes or no.
  2. Why?

Skip the “maybe” option for whether someone likes your product or not. If the answer isn’t yes, it is no. This is especially true when it comes to products and purchase decisions. From a data standpoint, you should treat your “maybes” as a “no”.

This will increase the number of respondents as well as the conversion rate on survey results. You may think you need a more complicated measurement. 5 point likerts, dozens of questions, Net Promoter Score.

Aside from production data like revenue, repeat customers and data on usage, all you really need to know is if someone likes your product and why. And a breakout of what % of your survey respondents like your product versus not liking your product. This is just as valuable – if not more valuable – than a traditional Net Promoter Score.

Keep it simple. If you need more intensive data, run a usability lab.

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.

Page 1 of 2

Powered by WordPress & Theme by Anders Norén