(Having trouble seeing the slides? Try here.)

Original article: RR for Test Doubles Presentation

Many people seem to interpret MVP as the first iteration of their product. Once they build that version, they can add more features, and users of the product will be even happier than before. Businesspeople sometimes talk about needing to build an MVP so they can launch and raise more funding.

If you are building out a half of a product as your first stab, you might as well just call it version one or iteration zero or something like that. No sense in polluting the MVP term.

In this article, I will argue that most so-called “MVPs” are not really MVPs because they are not focused on the process of learning, and as a result, wasteful. I think that there is a lot of value in not trying to build too much. This low-hanging fruit likely accounts for the proliferation of the term. But I think that a lot of the value of an MVP is testing the risky assumptions every startup has.

Definition of minimum viable product

Well, what is a minimum viable product, anyway?

A Minimum Viable Product has just those features that allow the product to be deployed, and no more. The product is typically deployed to a subset of possible customers, such as early adopters that are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information. It is a strategy targeted at avoiding building products that customers do not want, that seeks to maximize the information learned about the customer per dollar spent. “The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” The definition’s use of the words maximum and minimum means it is decidedly not formulaic. It requires judgment to figure out, for any given context, what MVP makes sense.

A MVP is not a minimal product, it is a strategy and process directed toward making and selling a product to customers. It is an iterative process of idea generation, prototyping, presentation, data collection, analysis and learning. One seeks to minimize the total time spent on an iteration. The process is iterated until a desirable product-market fit is obtained, or until the product is deemed to be non-viable.

Wikipedia on MVPs, all emphasis mine

The reason landing pages are so popular as a form of MVP is not because they are the easiest thing to build. Often times they are very easy to build, but that is not the whole reason. The reason is that they often give a good bang for the buck (or time spent, ROI, etc.) for your current assumptions. With a landing page, you can test whether people understand the idea you have, collect metrics on the best ways to attract users, and whether anyone at all will sign up.

Yes, at certain points, your MVP might actually be a landing page with a value proposition and a way of learning from it. It might be going to a bus stop and convincing people to get in your car to test a new carpool web app idea. Sometimes it’s a super-limited version of your product, meant to test a set of assumptions. It could be a paper prototype that you show to earlyvangelists to talk about your value proposition. It might be you just pretending to be a magical algorithm that solves your supposed customer needs.

You should start with the riskiest assumptions that you can test and try to make them fail. Here is why you should start at the bottom of the risk validation pyramid.

What do you want to learn?

Here are my concerns when the term MVP is used loosely:

• there is little emphasis on what assumptions the MVP seeks to [in]validate,
• there are no clear success or failure criteria, and
• there might be an easier way to learn as a result.

Here’s how Eric Ries frames this anti-pattern:

Most entrepreneurs approach a question like ["how many customers will sign up for a free trial given what we believe is enough information?"] by building the product and then checking to see how customers react to it. I consider this to be exactly backward because it can lead to a lot of waste. First, if it turns out that we’re building something nobody wants, the whole exercise will be an avoidable expense of time an money. If customers won’t sign up for the free trial, they’ll never get to experience the amazing features that await them. Even if they do sign up, there are many other opportunities for waste. For example, how many features do we really need to include to appeal to early adopters? Every extra feature is a form of waste, and if we delay the test for these extra features, it comes with a tremendous potential cost in terms of learning and cycle time. The lesson of the MVP is that any additional work beyond what was required to start learning is waste, no matter how important it might have seemed at the time.

Eric Ries, The Lean Startup pages 96-97

Let’s pretend you have an idea for a software product. You think through all of the different features and what you think people would most like, and select what you consider to be the most valuable, easy to make, and coherent subset of those features to build in a month. Then you build those features. You launch the product, and no one seems to be interested. What do you do?

If you create something and don’t have a good way of learning from what you are doing, your options boil down to:

1. Retry: Change the product in some way and try again. Maybe it was that non-essential feature that you left out of the last release.
2. Travel: Pivoting (another often imprecisely used term) is moving in a slightly different direction with one foot grounded in learning. Traveling is heading in some direction with the product or feature without having validated your hypothesis.
3. Fail: Quit without having learned much. Try another idea.

(I originally thought of this in terms of abort, retry, fail, but as the failure of that error message centered around the confusing nature of the words, decided to make it a bit clearer instead.)

All of these are outcomes are undesirable due to the amount of waste involved (some sum of human energy, money, and time spent without much learning.) Again, this probably stems from not testing some risky hypotheses at a small scale.

Poorly defined expectations lead to fuzziness at the time you most need clarity. When done with an experiment, you should have a clear sense of “is this the outcome that I wanted to see or not?” If the answer is a clear no, you can think about what you might need to do to get a different outcome. If the answer is yes, or better than you expected, then you can continue with confidence. If you don’t say up-front what customer actions you expect from a certain action, you’re left with lukewarm results that anyone can interpret in any way.

The overhead of learning

MVP, despite the name, is not about creating minimal products. If your goal is simply to scratch a clear itch or build something for a quick flip, you really don’t need the MVP. In fact, MVP is quite annoying, because it imposes extra overhead. We have to manage to learn something from our first product iteration. In a lot of cases, this requires a lot of energy invested in talking to customers or metrics and analytics.

Eric Ries on MVPs

I like this quote because it introduces the idea that thinking about what we want to learn is critical when we build. The build-measure-learn (BML) loop is how things play out in time. However, we should first focus on what we want to learn, and then how we are going to measure it to dictate how we should build what we are going to build. The BML loop should be thought through in reverse to ensure that the experiment results in learning. The quicker we can get through that cycle, the faster our startup moves. Without learning, we aren’t really going through the cycle, and as such, are cutting out the feedback portion of the feedback loop.

The key questions

So here are my new questions for MVPs. If someone says they intend to “build an MVP” (the build part itself might be a tell), I am going to ask:

• What are you trying to learn with this particular MVP?
• What data are you collecting about your experiment?
• What determines the success or failure of the experiment?

Original article: Signs You Aren’t Really Building a Minimum Viable Product

(Having trouble seeing the slides? Try here.)

Original article: Making Recommendations with Apache Mahout Presentation

The talk

You have a reasonably well founded position, you almost certainly have enough to write about. You have arguments and counterarguments for the major things people are going to say. You have experiences that no one else has. So just write them out. Who can argue with what you have experienced? You’ve already done the hard work of thinking about this problem, why not get the benefits of writing it out? If anything, this will help clarify the thoughts that you have.

The specific phrases don’t matter, as long as you are getting out the main thoughts. You can always refine it over time—the great is the enemy of the good here. That’s what the edit functionality is for. I know you would love to include a beautiful graph or venn diagram to illustrate something, but just say it now and add it later if you must.

There is this nagging thought that says, “what if someone on the internet thinks I’m WRONG??“. That’s a vestigial fear coming out, like being worried about tigers or alpha male chimpanzees. The more rational concern, and the one you should focus on, is “does anyone even know that I exist?” The only way to solve this is to write.

You’re worried about being controversial? That is a good problem to have, it means someone cares enough to write a reply. And if you are wrong? Well, you learned a lot quicker than you would have if you kept it to yourself. Seems like a good deal.

Just ship it.

Just ship. Other people might want to read it. That publish button is scary? Just schedule it for two days from now or next week and keep on writing in the meantime. You’ll have forgotten all about it when it publishes and be surprised when someone asks you about the new post. “Which post?”

Writing might be the single best way of spreading knowledge that you have. It just makes everyone better off, including you. Instead of rehashing the same stories and thought patterns in your mind and with others, just write about it and refer them to the article.

Don’t have much time to write? Put down a nugget of inspiration for later. Just put the minimum intelligible sentence, and maybe instinct will take over. Just write it up real quick while you are thinking about it. You can surely find thirty minutes to just write what you’ve been thinking about or reading about. Could it be considered productive work if you are publishing something that will help your business grow?

Lastly, it might help someone else out a lot. It doesn’t take all that much time and you will feel better having done it. When you look back on this year, the posts that you have written are going to stand out in your mind as a high note. You will get better at writing and the next post will be even easier.

Wrap-up

Meta-reservation: I was worried about publishing this post. Then I scheduled it for a week and a half away.

Phew, that was quite a pep talk.

If you ever want something to write about, let me know and I’ll try to help out!

Original article: How to Write Without Reservations

• hearing about something
• reading a book about it
• knowing a similar technology
• writing a Hello World program
• doing a small project in an area
• having years of experience doing something

I think there could also be a weighting as to how much the person feels like they know a particular area. Maybe they “read” a book but didn’t feel like it really sunk in. Perhaps they don’t know a particular technology, but have two good friends who are well versed in that technology and can help in a pinch or introduce them to people in that space. In this way, an overall view of what a person has done and may be capable of can be more easily assessed. Take for instance someone has not done much C# but has done a lot of Java development. By understanding that these technologies are similar, someone outside of the development field can understand that this person has a higher capability for C# than in, say, embedded development.

The model might best be represented by a visualization. It could be shown as graph sized by relative experience. A large bubble means more experience, and smaller bubbles represent less experience. I could see using software to make this visualization dynamic to visualize progress over time and enable different views and drilldowns. There could be a weakening aspect for experiences that were a long time ago to show knowledge decay or obsolescence. Imagine that you could see what someone’s knowledge in a subject has been for the past five years. If I have knowledge years ago in a technology that is moving super-fast, it might not be all that useful. However, many years of experience in a slow-moving environment is a good thing to know about. I feel like some sweet images would be really helpful to illustrate this, but I’m going to punt for now.

Seems like there should be something out there like this, but I haven’t seen much. I have seen nice views of resumes (mostly by designers) but nothing for the average person. Perhaps this is a tangent, but I think it would be cool.

This portfolio model helps people see what they should strategically target to move to where they want to be. When someone notices a difference between the experience they have and what they would like to do, they can choose to bone up in the space that they want to be more active in and more actively try to pursue projects in that area. Seeing a disconnect promotes a mindset change. Also, it helps people view their own competence objectively, and leverage that knowledge going forward. Hence, this model and accompanying visualization has value whether it is show in private or public. It could just be a strategic planning tool, but could also be a new way to understand what people are good at and trying to do.

It could be useful for consulting/contracting organizations to get a feel for what their levels of expertise are and how to most actively manage them. If more competence in an area is desired, specific steps can be taken to increase that area.

Could you see using something like this for your resume or for evaluating working with others?

Original article: Formal Skill Modeling

It’s useful to note that all of the following stages are generally in play at any given time. If you focus only on the future, you might starve. If you focus only on the present, you might become short-sighted and hurt long term results. The idea is that one should have:

• a list of skills that have general value today,
• a list of skills that are becoming obsolete, and
• a list of skills that just might become very useful in the near future.

Essentially, it’s skill diversification, much like people diversify stock holdings.

The Cash Cow

This is something that you are very good at and is currently in hot demand. It differs from a core competency because this is something that you can make money doing for the near foreseeable future. This is web programming (and others) in the late 1990s. This is probably Ruby (and others) today. It might be something else tomorrow. Hopefully you will have learned enough about tomorrow’s cash cow in the second phase (small bets) to be good at it when it changes.

There are different kinds of cows. It could be that COBOL programming is the thing you are best at and can easily find a variety of work for. This would fit the criteria that I laid out. You might have some that are solid, and some that are getting to be less profitable.

If you follow this general process, you will eventually have multiple focused competencies that can be used in the future. This helps ensure losses in one area can be absorbed in another. For example, if for some reason the technology that you are working in suddenly comes into huge legal problems, you are alright because you have other skills that are useful.

It helps to have some competencies be similar so that you can leverage what you know, but it also helps to diversify. In either case, being able to quickly shift what you know and learn something new is going to be a benefit. If dinosaurs could adapt to changing climates, they would have been in much better shape.

Small bets for the future

The race is not always to the swift, nor the battle to the strong, but that’s the way to bet.
- Damon Runyon

It’s hard to predict the future. If you had a time machine, it would be pretty easy to beat the stock market (see Back to the Future: Part II.) What people commonly do today is to spread their investments out with the expectation that while any one of them might not do well, when all of the investments are taken into account they will be better off than if they held the investment money under their mattress. They also take on less risk than putting all of their money into one investment.

Likewise, the point of this phase is to place small bets on skills that you think will be big at least in the next few years. This satisfies the need to explore and contribute to new initiatives, while limiting the downside that new things may bring. For example, putting all of your investment in learning a proprietary technology and doing projects with it might be a good choice if it takes off. However, if it doesn’t take off, you might be out of a lot of time invested. Generally I’d rather invest than not invest because you end up learning something you can use later, but there is an opportunity cost to consider. Maybe you could have gotten a little better at something that would be more useful.

Later, when the future is clearer, you can double-down on the things that worked well. You gain information due to being an early adopter, and win out by having more experience in a given area. This could be working with Rails in 2006, or maybe some HTML5 + Coffeescript experimentation today.

Investors might be successful if they just diversify, but some do analysis as well to try to pick better stocks. With limited capital (time, attention, energy), it pays to think about what technologies might gain wide adoption in the future. Also, there is the added consideration of: “what skills do I want to have?” If mobile development does not appeal to you, it makes less sense to learn more about it than another hot technology.

A good example of some analysis in this regard is the Thoughtworks technology radar. They give an in-depth look at what technology choices to stick with, adopt, and move away from. You might agree or disagree with their choices, but if you are at least aware that a choice exists, you can potentially make an investment.

The earlier you invest in a technology the more likely that that investment will pay out over time. Instead of four good years, you might get six. Although on the flip side, you get more information as the technology gains adoption. However, as I previously wrote, being first in the mind is enough benefit to risk trying a few technologies publicly, even if they fail. Some of the time things don’t pan out, but the rest of the time it looks like you can predict the future.

Branching out

At the same time, it is possible to learn more about surrounding fields and seemingly completely tangential ones. This is the longest view possible and also has larger potential gains. It takes a long time to become an expert in one field, and it’s helpful to understand other fields to try to be at least oriented in a certain field. Again, this branching out takes into consideration that short term and medium term needs also need to be fulfilled for success.

If I am a specialist in software development, it helps to branch out to related fields, like project management and gaining experience with running a business. These are clear wins. If I am interested in using some newer software techniques, I might want to learn more about bioinformatics to make the most of the tools that already exist, or more about the hard sciences to see what the open problems are so I can contribute to them. Basically wherever it makes sense to steal concepts or work with a certain industry.

These are likely long-term studies. One does not become better at them without sustained effort. But half an hour a day for five years adds up (about 900 hours if you take some holidays off.) For some, this might be continued formal education, for others, self study. Regardless, it adds up to more interesting work and increased options.

The nice thing about studying something mostly new is that the return on investment is significantly higher than learning a little more about something you’re already an expert at. If a professional programmer spends twenty hours reading a programming book, will she even move the needle on their professional skills? However, if this same hypothetical and clearly stereotyped-as-introverted programmer reads about how to interact better with others, this has a potentially huge benefit.

Synthesis

I’ve been trying to work the career calculus link in all post, but failed thus far. Now I feel better. This one is all about learning every day.

I think the overall goal is to maximize long-term value creation and ensure cash flow stays at an adequate level. I think opportunities should be evaluated for their lifetime value and short term impact. Value could come in terms of financial compensation, contacts, experience, work environment, and more. If someone wants a Fortran programmer and I’d like to move away from that technology, the other aspects of the project had better be good enough to justify having more knowledge about Fortran and not being able to do something else.

I’ll have more to say on formal skill models on Thursday.

How do you think about opportunities and skill acquisition? What did I miss or overgeneralize? Thank you for reading and leave a comment with your thoughts!

Original article: How to Look Like You Can Accurately Predict the Future of Technology

I am working with Jason Yip to better understand how people think about solving problems. Specifically we are interested in the differences between “experts” and less expert people in a methodology.

For this first step, we are looking to collect challenging Agile scenarios. These should be the hairiest, most difficult, most challenging Agile situations you’ve found yourself in. The preference is for scenarios that you have directly experienced yourself rather than hearsay or hypothetical scenarios. It’s not important whether you were successful in meeting the challenge; it might even be better if the scenario is one where you failed. We’ll then pose these scenarios to different people and see how they think about solving the problem.

We are doing this to try to improve everyones’s understanding of how mindsets change with experience and potentially to help people gain mastery faster in the future. Also, it could help with debugging mental models, which would be useful in other contexts (lean/agile adoption, lean startups, etc.)

Here are the three specific things that I am asking. I am hoping that it will take ten minutes or less. Thank you!

(Having problems seeing the form? Click here.)

The method to the madness can be seen here.

Original article: Think Like an Agilist Challenge

Here are some indicators that there is work that you need to do that is not captured in your current project management system. They should work well with almost any agile project management system. It’s a good way of finding and capturing latent stories for people on the project to see.

Patterns to watch for

“We need to revisit this in October.” or “We should probably do this at some point.”

Create a story for this item. Regardless of when you revisit the item, it’s nice to visualize the work that you believe you should do at some point. This can be effectively prioritized against the other work. You capture that you have something to do and can plan around it. This is useful in capturing work expansion as it happens.

“This isn’t perfect, but it works for now.”

Add a task to refine whatever the item is. I’m a big fan of progressive enhancement for stories. Get the basic thing done, and then you can add polish later.

“Hmm, that’s a bug, but I don’t want to fix it right now since I’m trying to finish something else.”

You can quickly add this. Put a quick description of where you were, what you did, what you saw and what you expected to see instead. If you want, speculate on what might have caused the problem. Then you can move on knowing it will be taken care of soon.

“I have this crazy idea that I haven’t discussed with the team”

Don’t add this as a story, yet. You’re only cluttering up the backlog, making it less valuable. First discuss it with the team, and if it is something that you plan on getting to soon, you can add it.

A long discussion in the group chat room or an important email

If there are things that pertain to the story that you are working on or will be working on, copy and paste the direct text or a public link to the text that is relevant. If there are other documents or relevant images, link these as well. Especially with the chat room, you are already having these conversations and making decisions, so you might as well put these somewhere so that everyone will see the conversation when in the right context. No need to have the same conversation twice or need to hunt through a long series of emails to get to the relevant information.

Other thoughts

I think that this technique should be coupled with good backlog management to ensure that the highest priority items are being done and obsolete stories are being culled. If your backlog is too big, you will waste time and energy just managing it. Consider trimming it aggressively. Any truly important things will keep coming back.

I find that cultivating this practice ensures that the team communicates well and everyone knows about how much important work remains to be done. There’s much less “oh yeah, I forgot to include you on that conversation.” It makes the ephemeral more concrete, and leads to people trusting that what is in the system is very close to what actually needs to be done.

When do you add something to your list of things to do? When do you wait to add something?

Original article: Spotting Hidden Stories

Here is my ohours profile. You can subscribe to be alerted when I post a new office hours session. I set up a few hour block of time and a location, and you can schedule a meeting within this time period. I figure that there’s little potential downside (as I could work at the place in the event that no one shows up), but potentially much higher upside. I always learn something new when talking with someone, so this should be a great use of time. When’s the next one? A couple days from now. Sign up now!

If you have any questions about a project that you’re working on, something that you would like to do in the future, or thoughts on life, I’d be glad to talk about it.

Questions for you

What reservations do you have about doing something like this? Do mornings work, or would dinner or late night meetings be better? What side of town would work best for you? Is half an hour good and then extending it if there are openings? Do you want to meet with the other people there too? It would be nice to get in a good cadence so that I could regularly schedule meetings, but I could see switching up times and locations to be conducive to meeting with people. Right now I’m focused around northwest and northside Indy since it is the most convenient for me to go to, but I could see having one downtown as well. Thanks!

Original article: How to Sign Up For My Office Hours

My thoughts

The key consideration in my mind is something along the lines of BATNA (best alternative to a negotiated agreement.) This concept applies to many business situations. In order to effectively negotiate with someone, you need to realize your next best alternative to negotiating. Perhaps your company is in good shape, and the deal would only be slightly beneficial. This puts you in a better negotiating position because you know that you can walk away from the deal without worrying. If your best alternative is your company going under, you are more likely to try to make the deal, even if it is at a slight disadvantage to you.

How does this apply to technical cofounders? Simple. They have a lot of alternatives to joining your early-stage company. They could do lucrative consulting or contracting. They could be working for better equity stakes at other companies. They might want to start their own company instead. Hmm, 5% equity at your company or 100% equity at their own company? Why would they work for a split of equity when they could be bringing down cash money for contracting, regardless of the success of the eventual product?

The meaning of this is that the company that an entrepreneurially minded developer joins needs to be pretty darn good. If you’re looking to recruit/enlist others to an idea with no product or no traction, it starts with you. Learn how to do as much as possible, and show that you can hustle. Learn how to code to throw a prototype together, and if you don’t do that, learn how to do some wireframes or at least talk with engineers. There are many tools out there that will get you most of the way, and you should gain experience using them so you can bust them out whenever necessary to get your startup moving along. You should know that people who know how to code Ruby on Rails probably have done some database work—be active in the local entrepreneur circles as well as the local tech circles to start getting your bearings.

Why should business cofounders in the technology industry understand tech well? Well, take it from Paul Graham:

In a technology startup, which most startups are, the founders should include technical people. During the Internet Bubble there were a number of startups founded by business people who then went looking for hackers to create their product for them. This doesn’t work well. Business people are bad at deciding what to do with technology, because they don’t know what the options are, or which kinds of problems are hard and which are easy. And when business people try to hire hackers, they can’t tell which ones are good. Even other hackers have a hard time doing that. For business people it’s roulette.
– Paul Graham, in 2005

The other main point is to demonstrate that you have some hustle. Do you have a record of being able to raise money? Do you have contacts in the industry you are interested in working in? Perhaps something else that the tech cofounder doesn’t already have or is not interested in. And so forth.

The posts

Andrew Chen’s post

Seth’s blog post about this

An IndyStartup post about this general topic

A good Hacker News post that a business-minded guy put out there. This is the example of how to do it right (hustle, knowledge, and social proof in the comments to boot.)

Interesting series on becoming your own tech cofounder

What if 1000 entrepreneurs learned to code just a little instead of lamenting the lack of engineers?

An interesting flowchart of tech cofounder equity. Potentially the most suited to the engineering mind.

Excellent piece on how to evaluate any company in its early stages, from a developer’s perspective generally. Get in their shoes!

Survey of actual developers. Again, this is pure gold if you want to understand what technical cofounders or early stage employees are thinking about and motivated by. How they look at potential companies and the “biz guys”.

Beating a dead horse by now, but another post about working for free and what developers look for in a business cofounder.

Last one!

What are your thoughts on this? Post a comment below, and thanks for reading!

Original article: “Finding A Technical Cofounder” Blog Roundup