Agile Archives - imagine.GO

We just wrapped up our 11^th business building block sprint on Key Activities. In summary, the sprint for Project 1.11 on Key Activities completed 2 objectives:

Questions to ask on the canvas for the Key Activities
Explanation regarding how to define and stick to only the necessary Key Activities

1. Questions to Ask on the Canvas for the Key Activities Block

We defined the questions that should be added to our business model canvas for helping practitioners define their Key Activities.

What Key Activities do our Value Propositions require?
What Key Activities do our Channels require?
What Key Activities do our Customer Relationships require?
What Key Activities do our Revenue streams require?

2. Do Only the Right Key Activities

The first part of this sprint is about defining the work tasks you need to do to deliver your Value Proposition. However, there are a lot of ways you can waste time doing the wrong things as your work scope begins to creep. So how do you go about keeping to only the right actions that you defined in the Key Activities block? I advocate that you apply the rigors and methods of the Lean Startup to your healthcare business model – including all technology, process, and business functions.

By definition, Minimum Viable Product (MVP) is the version of a product that is made through one cycle of a ‘build-measure-learn’ loop, done as quickly as possible. Accordingly, the work tasks (Key Activities) that are required for a build must include only those that meet the minimum viable product. Although this methodology was first applied to the world of software engineering, I recommend using it across the board for all work tasks.

The term Minimum Viable Product gives some people pause. Many default to the adage that to deliver value, we must give our customers the maximum product, not the minimum. Sometimes our attempt to provide maximum value results in bloated or inconvenient products loaded with useless features that diminish, rather than enhance, the value of the product. Think of a product in its two basic value points: form and function. Stylistically speaking, function is what a product does and form is how it does it. We discussed the need to build an “expected” form, or what we call Experience, in our building block on Experience. This expected form also implies Key Activities on your part. Be prepared to collect necessary information and build it into the Key Activities in your business model.

But at the same time, when it comes to function we advocate that you only need to do the work to build the minimum viable version. This reasoning examines your Customer Relationship, built on the premise that you have a Value Proposition that will solve your customers’ Job-to-be-done (JTBD). Your Value Proposition should do that and no more than that, otherwise you are throwing energy and resources after an unknown. If you agree with this logic, then you must apply this rigor to what work tasks, or Key Activities, you set out to do as part of the functional delivery of this Value Proposition. Focus on function rather than form. The basis of your trust relationship with the customer is a two-way exchange of value. If your product is all style and no substance, then you will lose your customers. If your substance far exceeds your customers’ needs, then you are similarly doing more harm than good, as the extra value is unrealized. An even worse case is that customers end up confused drop it altogether. Ultimately, only do what is necessary to build your MVP.

Do not forget that you are running a business and that there are laws around compliance, fillings, and finance that you must follow. These are part of your Key Activities. If you do not list the work on these core operational fronts, you have an incomplete picture of the workload and resources required, which will inhibit you from determining the Key Resources and Key Partners you will need for a concise delivery. Therefore, as is often the case, you will find out too late, and it will either shut your business down or cost you an exponential amount to resolve.

In Summary

In conclusion, we advocate that you identify your Key Activities by identifying your MVP, and adding in the other required business tasks you needs to remain compliant with laws and financial transactions. By only building what is deemed most valuable to the customer, and progressing through iterative builds, you ensure speed to market and successful releases. When you are wrong, you fail fast (and cheap). MVP assumes that you iterate until you find the ideal solution. Start small and gradually add on, based on your customers’ needs.

Take time to incorporate these approaches into the Key Activities block in your business model canvas. Regardless if your business model aims at Patients, Providers, Payers, and or Purveyors, defining the Key Activities will keep you focused on doing what is relevant to your Customer Segment’s Jobs-to-be-done and your Value Proposition. Anything else is a distraction and will lead to straying from your business model.

What is Next?

I will be publishing the findings from 1.12 Key Resources and 1.13 Key Partners over the next few weeks. Next up on the modelH Co-Creation Forum, we are going to do a short two-week sprint on Costs and Revenue.

Interested in what we are doing?

Step up to the plate and become involved. We have just a few key modules left to discuss in the proposed modelH canvas. Please join us, make your contribution, and be recognized for helping to develop a sustainable future for the US healthcare system.

Click here to learn more: http://bit.ly/modelH-keyresources
Click here to join: http://bit.ly/modelH_joinup
Follow us online at: https://twitter.com/ModelHForum

To your health,

The Team at imagine.GO

Minimum Viable Product

Customers want what they want not what you want for them. As such, the discipline of Minimum Viable Product is one I hope you learn more about soon. I think Eric Ries says it best, but I wanted to sum up my perspective for you.

MVP as a methodology enables designers to determine whether people want what they are building – in a manner that gauges acceptance and demand – yet preserves capital and time. This is accomplished by allowing designers to validate assumptions about their “product” in two important aspects: its value and the demand for it.

By definition, MVP is the version of a product that gets built through one cycle of a build, measure, learn loop – as fast as possible. Once the MVP is confirmed (keep in mind, it may take a few iterations), other lean methodologies can be employed to build upon it.

MVP = 3 things: value, use, & speed

Valuable – understand if your product is valued

Make an assumption about the value-exchange created by your product and test it thru iteration until it validated or dropped. Value is defined through the lens of the customer – not what you want for the customer. If no value is confirmed, no product should be created.

Usable – make your product usable and it will get used

MVP asks that you focus on delivering product experience – not on documentation or large feature sets. Usable is more broad a term than just usability. The real test is the usage of the product in the manner you anticipated, not necessarily its first pass at usability. Although you can’t get usage without usability, so be careful not to forsake usability for speed and minimum moving parts. Form and function must appear simultaneously – with minimum function allowing for a simpler form.

Speed – take your product to market quickly

By only building what is deemed most valuable in order of priority to the customer, and progressing through iterative builds, you ensure speed to market and successful releases. When you are wrong, you fail fast (and cheap). MVP assumes iterate until you find the ideal solution. Start small and add on based on customer need.

So how can you best focus on your (MVP)?

Getting to MVP is actually fairly simple. I suggest this path.

Start with the features that allow the “app” to be deployed, and no more. Be disciplined here. Do not let your shovel makers and hole diggers get the better of you. Get to the orange juice quickly. You can work on other recipes soon enough.
Launch to your defined early adopters (they are forgiving) and get feedback. Oh yeah, it stands to reason to work with people who want to work with you. If you know people do not like the taste of orange, avoid them. Finds the ones that do and test your MVP with them first. If you cannot “sell” the vision to your early adopters how will you do it with anyone else?
Add what is relevant to extend value incrementally. OK, do not let the shovel makers and the hole diggers add a little bit at a time and test it. Make sure you are keeping true to the original “value” part of the app!
Now just keeping doing that!

This BLOG by Alexander Osterwalder is very useful for helping you get started.

By the way, you should not use MVP as a start if you are not committed to proceeding with other lean methodologies afterwards that allow for a continued iterative process – lest you lose the “value” in your product. More on this at another time.