MBA227: The Minimum Viable Business

11/16/21 • 21 min

1 Listener

Ian Reynolds discusses how to discover the right solutions for your customers and then deliver them quickly. Show Notes

Many organizations, especially as people are trying to work in more Lean and Agile ways, work towards producing a minimum viable product (MVP) and move on after achieving it. These organizations aren’t thinking about the value that could be delivered after the MVP.

They believe that if they put a minimum viable products in our customer’s hands, they know whether or not it’s a great product. Instead, people need to be working towards a minimum viable business as opposed to the minimum viable product. You could put a great product out there, but if you haven’t designed it to solve for the customer’s ultimate needs by testing it and getting early feedback

and created a degree of stickiness in a business model that will help you retain and add clients, you have a problem.

You don’t necessarily have a business and you haven’t necessarily solved the problem. Over optimization towards what you believe to be a viable product is not necessarily that MvP. It’s a business model that’s going to have sustainability.

What’s Valuable to Customers

When you’re developing a product, the easiest person to fool is yourself. You may believe that you have a great product, but you need to test it to validate that belief. That could be as simple as using a survey to check the validity of your idea. Building a product (even a scaled-down version of a working product) is a very expensive way to test an idea.

If you build the product first and then try to go out in the market and then make the adjustments, you’re going to have to build it again.

Faster Delivery

There are two major inhibitors to speed to market. One is trying to do everything yourself. The desire to understand exactly how the product is built and have too much control over the process of building that product is not efficient.

When you’re building a product, it’s not reasonable to be so in the weeds that you’re concerned about using a specific technology or growing to an understanding of how everything works. When starting your business or starting your MVP, don’t try to have one person do everything. Have people that are specialized in their given fields and fractionally use their time.

The other big impact to speed to market is if you don’t have a needed skill set in house. Training that skill and building competency can take a long time. You don’t necessarily have to hire for it as that could be much more expensive than using an outside party.

Listen to the full episode to understand how to test and discover the right solution and how approaches such as DevOps can help accelerate both discovery and delivery.

YOUR HOMEWORK
First Tip: Look at what the biggest players in the market are doing in terms of their engineering culture and then figure out what is it that they’re doing efficiently that you can copy. Don’t try to invent things yourself or come up with a new process; figure out what they’re doing and just copy it.
Second Tip: Analyze the opportunity cost of doing something in-house versus using a third party by looking at what an outside party can do for you and what specialization they have. If they could solve the problem for you quickly, maybe they can do it much more cheaply.

IAN Reynolds

Ian is the Chief Solutions Architect at Zibtek and Head of Venture Partners at Golden Section Studios. In his role as Solutions Architect, Ian matches business needs to technical solutions that solves the customer’s problem.

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

More Popular Episodes

Ian Reynolds discusses how to discover the right solutions for your customers and then deliver them quickly. Show Notes

and created a degree of stickiness in a business model that will help you retain and add clients, you have a problem.

What’s Valuable to Customers

If you build the product first and then try to go out in the market and then make the adjustments, you’re going to have to build it again.

Faster Delivery

Listen to the full episode to understand how to test and discover the right solution and how approaches such as DevOps can help accelerate both discovery and delivery.

IAN Reynolds

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

More Popular Episodes

Previous Episode

MBALC: Elon Musk’s 5-Step Design Process

In this lightning cast, we explore the 5-step design process Elon Musk uses for SpaceX to innovate and get better results.

Show Notes

In a recent interview, Elon Musk shared the 5-step design process he uses at Space X to achieve better results. Below are the details of this design process.

Step 1: Make your requirements less dumb.

Make sure you start with high quality requirements and that you truly understand the ‘why’ behind each. Simply using requirements because someone told you that’s what they want makes your requirements dumb.

“It does not matter who gave them to you. It’s particularly dangerous if a smart person gave you the requirements because you might not question them enough. Everyone’s wrong. No matter who you are, everyone’s wrong some of the time.”

Elon recommends that for whatever requirement or constraint you have, it should come with a name, not a department. That’s because if there’s a question of concern, you can’t ask a department. You have to ask a person. The person who’s asking for the requirement or highlighting the constraint must agree that they will take responsibility for that requirement.

If you fail to do this, you may run into the situation where some random person who’s no longer with the company came up with the requirement off the top of their head with no foundation in a real need. That’s a dumb requirement.

Step 2: Delete the part or process

Look critically at the process or piece you’re developing and try to remove pieces instead of always adding new things. Work to understand the value that’s added by each part or each step in the process and reduce or eliminate those that don’t add value.

“If you’re not occasionally adding things back in, you are not deleting enough. The bias tends to be very strongly towards ‘Let’s add this part or process step in case we need it’. But you can basically make in-case arguments for so many things.”

Step 3: Simplify or optimize the design

Optimizing should only be done after you make your requirements less dumb and try to delete the part of process. The most common mistake you can make is to optimize something that shouldn’t exist in the first place.

Step 4: Accelerate cycle time

We want to reduce the amount of time from when we start working on something to when we finish. The easiest way to do that is to focus on one thing at a time and eliminate task switching. With that focus, you can get things done more quickly . . . just make sure they’re the right things.

“You’re moving too slowly. Go faster, but don’t go faster until you work on the other three things first.”

Step 5: Automate

Once you’re confident you have the right requirements with the right ownership, removed unneeded steps, optimized the design, and done things quickly, you can automate the process. Don’t spend the time and effort to automate the wrong thing or automate too soon.

Using Elon Musk’s five-step design process may help you and your organization to innovate faster and focus on customer value.

Latest Episodes

Next Episode

MBA228: Software Development Pearls

Karl Wiegers shares his lessons on requirements, project management, design, quality and more. Karl’s advice can make you significantly better at what you do.

Show Notes

Karl Wiegers started programming in 1970 and has collected 60 lessons he has learned in several areas of software development including requirements, design, project management, culture, teamwork, quality, and process improvement. Each of these lessons bring insights that can help you to and your organization to become significantly better at creating high quality, valuable solutions to your customers.

The Need to Iterate

Almost everything we do takes more than a single shot and design is a good example. The first lesson in the design category of Karl’s book is “design demands iteration”. There’s always more than one design solution for a software problem and seldom a single best solution.

The first design approach you come up with is unlikely to be the best option. A good rule of thumb is that you’re not done with design until you’ve created at least three designs, discard them, and take the best ideas from those three and build something better.

The same holds true for requirements. It will take a few iterations to get it right. These are cyclical things that you have to plan in your project management approach. You’re going to have to build in some reviews, get some feedback, prototype, and do some modeling to make sure we’re on the right track.

Icebergs are always larger than they first appear; that means that there’s going to be growth in the project. There’s going to be new information and new ideas that come along. You have to build in that growth and include contingency buffers into your plans. The bigger the project, the more unknowns and ambiguity and the more likely it is to change.

Understanding Stakeholders and Customers

Usage-centric development (as opposed to user-centric) is more likely to satisfy customer needs than product or feature-centered development. We shouldn’t care about features as much as you care about knowing what people need to do with the product. That’s the difference between the usage-centric approach and the product-centric approach.

That begins by understanding your stakeholders. Stakeholders are individuals, groups, or even systems who can shape or influence the direction of a project or who are affected by the project. To be successful, you need to identify your various user classes and identify who’s going to be the literal voice of the customer. Keep in mind that the customer isn’t always right, but they always have a point. Many times, the customer may ask for a solution, which may or may not be the right thing. To provide valuable solutions, we need to understand the underlying problem. If the solution they propose is the answer, what is the question?

Listen to the full episode for more lessons and advice on stakeholders, quality, applying what you’ve learned, and more.

YOUR HOMEWORK
Pick two areas you want to get better at and vow to spend some of your time on the project learning about those areas. Look for opportunities to apply that new learning on your project and perform in those areas better than you would have before your commitment to learn and develop your skill in that focus area.

Links Mentioned in this Episode

Karl’s Personal Website – KarlWiegers.com
ProcessImpact.com – Karl’s business and book information
Information on Karl’s book, Software Development Pearls

Karl Wiegers

Karl Wiegers is an independent consultant, author, speaker, and thought leader in the project community. His books on software requirements are considered required reading for Business Analysts and Project Managers. As a consultant and trainer, Karl has worked with more than 100 companies and government organizations of all types, helping them improve the effectiveness and efficiency of their software development activities.

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.