Use a slack channel to add innovation to your community.


Want to get more innovative thinking within your team? Here is a way to stimulate it:

  1. First, go to your company slack channel and create the “room_of_ideas”.

  2. Pose a challenge to your team to join the channel and contribute an idea a day.

  3. Do this for a month and then have a retrospective with participants.

What will your team get out of this?

  1. Your team will be more creative and happier. If you give them an outlet and they feel that it is ok to use it.

  2. Your team gets ideas. Some of these might be good. Some might spawn bigger discussions and could actually turn into something.

  3. Your team gets a good sense of problems. Ideas are solutions to a problem. Take any idea that was posed in your slack channel and ask yourself, “What problem does this solve?”. Now, take those problems and start grouping them together. You can sometimes find recurring themes. These problems are really what you want. You can do a focused brainstorm on the problem alone if enough people find this common problem important.

Here is what we learned.

First off, it is fun and not intimidating after you get into this.

  • I found myself on the lookout for good ideas. Sometimes I would queue one up for the next day.

  • I found that they came in bursts, usually when I was doing something that I didn’t expect.

  • My ideas started off as being big and lofty, but later in the month they were very authentic and practical.

  • The best ideas came in the moment when the problem was right in front of you.

  • There were reoccurring themes.

  • After one month we still continued to submit ideas.

Why does this work?

The value isn’t in the ideas that form, it is in the culture that you are creating.

Ideas are always forming and vanishing - you have to write them down to harvest them. An exercise like this gets people to become idea fishermen. Ideas are like dreams, you have one, it is vivid and immersive, then suddenly you can’t remember it. You need a place to put the idea as soon as it forms. I personally have tried notebooks and special apps, but then I just build up a bunch of stuff that I need to sort through and organize.

You need a community to help you remember to do this. With slack, it is very easy to start a thread about an idea that is interesting or to give folks a “thumbs up” for an idea. Then, each idea can become a catalyst where more information can form.

Probably the most important part is that it gets adults to play again. For whatever reason, we become very conservative about our ideas as we get older. I think maybe we are worried that if we give up the “one” idea, then we will suddenly run out of them and someone will take it.

By making ideas a fun social toy they become something to share and goof around with. This helps people relax and have fun solving problems as a team.

These were the common questions

Does the idea have to be well written?

No. It doesn’t even have to be well thought out. It is basically a sentence or two that tells of a solution to a problem.

How do you make it feel safe?

This is the most important part. You have to make sure that people’s ideas don’t make them feel judged. You have to make sure that any idea works; it isn’t about good ideas it is about a bunch of ideas. In fact, you might want to purposely put in some half-baked ones to show everyone that it is ok to not always be brilliant.

Why one month?

Limiting the time helps people feel like this is approachable. Think about your workout. If you had to do 1000 pushups you won’t even start. But if you do 10 every day, you can get there after 100 days. That actually sounds approachable.

What do you expect from this?

Three things will happen:

  • Expect to help form a better culture for ideation.

  • Expect to gather ideas.

  • Expect to find underlying problems.

Why give the company my best ideas?

You don’t. In fact, if you feel like one of your ideas is very personal to you, don’t share it. There should be plenty of others that you aren’t attached to.

What happens to these ideas?

In all reality, ideas can drain resources. The tweet size ideas I’m talking about take a few seconds to craft and might never go anywhere. It is a real investment to turn these ideas into product and that is the real work. Most likely, these won’t be used for anything other than to spark more conversations. It is the culture of creativity that we are working on building.


Give this a try and then please do a retrospective at the end. It would be really great if you could send me the results of these retrospective so that I can help to design this exercise to be more productive for other people.

Teaching kids to be entrepreneurs


I have a theory that seasoned entrepreneurs are not just pure talent and luck. Sure, there are some elements of that, but I believe that many come from entrepreneurial families. Someone in their past gave them a chance to fail early on and learn with no real repercussions. Until they are 18, they have a place to live, they have food, and they don’t have many responsibilities. What better time than to risk everything?

I’m a father now; I have an 8 year old daughter and a 6 year old son. I decided to test this theory by having them start tiny businesses early. Essentially, come up with something and try to sell it. The worst case is that they are no longer intimidated by the idea of taking a risk and it won’t be a mystery to them. The best case is that they might actually make some money and help pay for college.  I know this isn’t something taught in public school, and it is one lesson that I can hand off to them at an early age that can influence them for the rest of their lives. WIth this in mind, I set aside a couple hours a week to be with my daughter, Tessa. She can draw and is a good storyteller, so we decided to make and sell a book.

The rest of this article is an account of how I worked with Tessa and her entrepreneurial journey creating together. She had a whirlwind tour through how products and businesses are put together.

Step 1: Write a book: 2 months.

I would say that this was the most straightforward step. Tessa had read books and made simple ones before. The only difference was that she was going to have to do this in a digital format so that I could help her publish it properly.

To start, we made an outline and talked about how to tell a story. Tessa made up the characters and we put together a loose story around what they were doing. At the time she was pretty heavily influenced by Minecraft, but she has her own take on it.

Once the story was outlined, she drew the pictures to illustrate it. To do this, I had given her a “magic pencil” that she could use on an iPad to create the digital drawings that we needed. She would then share these with me through a Google Drive, where I could pick them up and put them through a coloring program. Finally, we imported the drawings into Sketch and added the text to it.


Step 2: Publish the book: 2 months.

Once we had the book, we decided we should publish it and see what we get stuck on. I choose to publish through Createspace since I had self-published there before. Our first challenge was figuring out how to turn all of our images into a pdf. Once that was done, we uploaded the pdf and found out that we needed at least 20 pages to publish. Tessa was a trooper at this point and if you get her going she can generate about 8 images an hour. It didn’t take long until we reached the required amount of pages. Once that was done, we created a cover, uploaded the book’s interior, and told them to mail us a proof.

The proof was great, and we immediately realized the images looked fuzzy and the text didn’t line up right. Back we went to Sketch to figure out how to adjust the resolution. We also had noticed several typos, and Tessa had some ideas on how to change the sentences to make the story flow better. Needless to say, it needed more editing before it was ready.

A couple other things stood out, though. Tessa needed a logo and to add copywrite. These became great lessons about what she could or could not own. It also became a lesson in how branding works and why people find brands so important. From that she created her Tessa Studio Logo on my whiteboard, and I took a picture so I could clean it up with Sketch.



Finally, Tessa and I had to talk about pricing and how that will work. To print the book, Createspace takes $3.65 and for distribution Amazon takes $4.10. We settled on the price of $10.24 so that she would earn $2.49 for every book purchased.

Then, Tessa pushed the button to publish, and we waited a few days to get approval from Amazon.


Step 3: An online presence: 2 months.

The book was published back in May, and the first question Tessa asked me was, “How many have I sold?” The answer of course was zero, but I love that she responded so quickly with the most obvious question. Thus, the work begins to find people who are interested in what she had created.

I think you should realize at this point that we are talking about a child who hasn’t ever been online before. This became a pretty high level discussion into how websites are created and why people use them. It is very easy to get too detailed too quickly, so as a parent you have to keep yourself from overwhelming your child with too much information. My advice, keep it simple, there will be lots of time to explain the finer details of hosting and computers.

The way I approached this was to explain to Tessa that she needed to tell people about the book, and it needed to be something they could remember. This also became her first introduction to the internet and how websites are named. After some thinking, we decided on naming it after her, Tessa Paulin. She bought the domain name and then we got to work on creating a website.

Website creation became another discussion about how much it will cost to host her website. We settled on after some attempts with other sites that we didn’t like as much. It had a simple enough interface and was a good starting point.

Now, all of this costs money. The website was about $120/year and a domain is $12/year. Here is a great opportunity for a discussion about financing. I offered to loan her the money, but she had to choose how to pay it back:

Option 1: As debt? She borrows the money and pays me back from her profits.

Option 2: As a shareholder? I give her the money and she gives me a share of her profits.

She choose Option 1, so we created a spreadsheet and started putting in the numbers.

The last step was that she needed to see how many people were visiting her website. This became an introduction into how websites collect data so they can do a better job of understanding who is visiting them. We created a Google Analytics account and connected that back into her Squarespace site.

Finally, everything was setup.


Step 4: Marketing: 1 month.

After we could see how many people were visiting the website, our conversation turned to how to get more visitors. Tessa and I did a brainstorming session and then prioritized what would cost the least and what would be the most effective.  Some of the ideas were to do a book signing, hand out cards, or to go door-to-door.

Tessa decided to make posters with tear off tabs. We found out that to print nice ones would cost a few dollars each, so instead she drew her own and used our color printer to make them. Then she put 6 posters up around the neighborhood.



The result was about 45 people visiting the website, and two more books sold. We started tracking everything on the spreadsheet.

It was really fun for Tessa to see how putting up flyers attracted visitors to her website and every now and then someone purchased a book. One customer even wanted her to sign it! I can’t think of any better way to start off.


You can visit her website,, and maybe even buy a book. As of this date, Tessa has sold 9 books and that helped her pay $22 on her debt. She only has about $110 to go and then she will make a profit. Tessa has many ideas for what to do next. She is considering doing a collaboration with one of her friends to make more books and doing a book signing at her lemonade stand. She also has a Twitter account so she can announce new books she comes up with.

A book really was the perfect starting product for Tessa. I had written one several years ago and knew how to work with the tools. Thanks to Createspace and Amazon, she wouldn’t have to do any of the manufacturing or distribution. She could concentrate entirely on the product and marketing.

This probably isn’t the case with every child. I think it really depends on them and what they like. For instance, I’m thinking of trying to do 3D printing with my son and then possibly selling the resulting products through Shopify, Etsy or Zulily. The goal is the same, though, I want them to try so this never seems scary for them later.


How to improve your product pitch.


If you are going to turn an idea into a product, one of the first tests is to figure out how to talk about it. This can be especially hard when you have an idea that is just forming or if the idea is so big that you don’t even know where to start. Ultimately, you don’t want to embarrass yourself if you are not ready. The general wisdom is to pitch all the time and to everybody you know, but maybe you want to sound more prepared and confident. How can you practice without making a bad impression? I use the the following techniques to hone a pitch in a week.

Step 1: Start by writing to a friend

I start by writing emails that I never send. It helps me focus when I think a real person is going to read this, and I need to clearly articulate my thoughts. Sometimes I choose different people because I know they represent a different type of audience. The pressure and expectations really help to force your idea into a form that is better explained.

So, who would be interested in your idea? Put their name on the email and start writing. You will need to think from their perspective and that helps me try to explain the idea in a way that makes it relevant to them.

Save that email as a file somewhere so that you can use it as a script.

Step 2: Fill out a lean canvas

The lean canvas is a one page concise business plan. I like to joke that it is a business plan in a placemat form. In the end, it is just a simple set of boxes that force you to think about the problem, solution, key metrics, and more. What I love about this concept is how it rounds out your thinking so you don’t forget any aspects that will make it a business.

This is the next step because you want to make sure your idea doesn’t have any holes in it.

Here is my lean canvas template as a Google doc. Feel free to make a copy for yourself.

Step 3: Make a pitch deck

Now that you have a way of talking about the idea and you have thought it through a bit more, it is time to turn it into a presentation. The Alliance of Angels has a standard pitch deck which is actually a great place to start. It looks like this.

PURPOSE : Declare what your company does in a single sentence.

PROBLEM : Describe your customer’s burning pain point.

SOLUTION : Describe your product and explain why it makes the customer’s pain go away. Use examples.

MARKET SIZE : Use both tops-down and bottoms-up. Segment and identify your sweet spot.

BUSINESS MODEL : Explain how you make money. State your customer acquisition cost and lifetime value.

GO TO MARKET : Describe your sales distribution model.

TRACTION : List current customers, partners, and users, as well as your pipeline.

COMPETITION : List your competitors and describe your economic moat.

TEAM : List your founders, key management, and advisors.

Your task is take all of your thoughts and ideas and put them into a pitch deck. Add some pictures, add some text, but get all of it in one place.

This step helps to turn your idea into a format that is easier to communicate to another person at a high level. Some of this won’t be relevant to you at this moment, but you should at least think about how you must answer the question.

This is a link to a Google Presentation that you can make a copy of to get started.

Step 4: Pitch to yourself

If you have a Mac, you have Quicktime. It’s a great little program that has one feature I find super helpful. Go to File -> New Screen Recording. Right there you can draw a box around your screen and record your voice as you explain your slides.

The trick is that recording yourself simulates the anxiety you can experience when you talk to people. Use this to your advantage to force yourself to string together words in a way that other people will understand.

On day one it will be rough. I budget about 2 hours to get through all of this and make a terrible movie. I usually keep one copy around and delete the rest.

Step 5: Listen to your video and make a script

Give yourself some time to recover from making the video and everything else. Once you are ready to start again, watch your video and transcribe what you just said into a script.

The real trick now is simply to do this over and over, repeating Steps 4 and 5. Find a quiet place and a time when you won’t be interrupted, and then simply pitch. Listen to yourself, update your deck, and pitch again.

The next day do it again for 30 minutes. Then do it every day in the morning for a week. Try to get the amount of time down; remove slides, add slides, and work on getting your voice to change tone.

It is a little like practicing an instrument, you simply have to take a little time every day and after a while you realize you don’t even need the deck anymore. Now you are ready.

Step 6: Turn the final results into assets

Before you call this done, you need to make sure you have a couple of assets pulled out of this.

  1. Post your best video somewhere and save the link.

  2. Put the script and the slide deck somewhere safe.

  3. Make an elevator pitch version of the script and a 10 minute format.


Pitching to yourself it a great way to get your pitch dialed in. It takes about one week to take an idea from an abstract notion and refine it into something you can explain confidently.

The best part is that you can always watch your video right before you are supposed to stand in front of investors so that you can reload it. If you need to add new information to the deck, then make more versions.

In the end, this technique is a great way to train yourself to explain something clearly when you don’t have a lot of practice talking in front of people.

As A Citizen I created User Stories



User Stories are hard to write, but they are worth it when you want to efficiently build or add onto a complex system. After more than 20 years of experience I would say this is the starting point for sorting out any idea. When encountering any large system, I always try to break it down into User Stories first. I use a technique that came about from writing code and doing requirement analysis that has served me and my clients well for finding the blind spots in an idea. Sometimes, this involves discovering missing functionality, separating out ideas that have been grouped together, and helping to prioritize competing goals. In this article I will take you through this process so you can try it.

Why the United States Constitution?

For fun I choose the United States Constitution as an example. From my perspective, it was a brilliantly designed blueprint to plan out the start and growth of my country. It amazes me that anything created by 55 people over 116 days could end up with ONLY a 4 page handwritten document. It came with plenty of flaws and drama, but it was designed to be expanded upon. That’s why we got 10 amendments with the Bill of Rights and later an additional 17 amendments. Think about that for a moment, this is essentially a rulebook that has been ratified since 1788 when New York was the 11th state to ratify it. It ONLY has an additional 27 amendments. I have seen countless business requirements documents that are many hundred pages and those were made with just a few people in the course of a week. It is truly inspirational to see something so important kept so concise.

Before we dive into this, I want you to realize that I do not have a legal background. I have an engineering background. I realize there is a massive body of knowledge that stems from the Constitution, and I certainly do not want to offend anyone with my interpretations. It ended up being an 18 page Google Doc. If you have some ideas or want access, please email me at:

If you want to just view it, follow this link.


A quick review about User Stories.

In case you don’t know what a User Story is, think of it as one sentence that explains what one type of user can do in a system. It is very focused on one feature and always written from the perspective of that user.

I like to think of them like the old Mad Lib sentences where you fill in the blanks.

As a ___ I want to ____ so that ____ (bonus) because _____.

You simply have to make a list of everything in this format. Sounds simple at first, but it makes you really think about who wants what sort of feature and why. The bonus of “because” is most useful when you hand this to engineering and design teams. This really helps them empathize with the user when they make decisions so they can possibly propose other solutions that solve the same problem in better ways than the originators ever thought of.

Step 1: Read and create your first draft User Stories

This is the most exhausting part, but you have to read everything in detail. For every sentence you have to ask; “who is this for?”, “what feature does this imply?”. From that, create your User Stories by filling in the blanks.

Tip 1: Split requirements: As you go along, keep an eye out for the word “and”. This usually implies two features in the same sentence. As part of the process, it needs to be rewritten as two stories.

Tip 2: Group by the same user type: You will find User Stories for the same types of users all over the place. As you go along, group them into the same places.

Tip 3: Give citations back to the original documents: The original documents could be everything from an interview, to a video, to a book. You need to include citations back to them so that you can always show where this came from. For example, I tried to tie it back to sections of the actual Constitution.

The end result can be fairly lengthy, but it is possible to reflect on the different sections independently and find inconsistencies.

Step 2: Refactor

Refactoring is a software engineering process where we restructure the code without changing the behavior. This involves regrouping, renaming, and removing duplicate functionality. When you have multiple versions of documents, you can find duplications simply by moving similar User Stories near each other.

In the case of the Constitution, I started to notice that there are certain roles that extended from another role. For example, an “Officer” was any “Citizen” who held public office. This helped simplify the role of “President”, “Vice President”, “Senator”, and “Representative” since I didn’t have to repeat the same stories in each category.

Another part I spent some time thinking about were the amendments. There are 27 of them and at first I had thought to tag each User Story with the amendment that it came from. Then, while refactoring I found that these should be preserved. In that case, I made sure that for the Citizen role, all the amendments affected the citizen. The reason here is that there is significant value in the order of these amendments. I eventually decided to keep them broken out for the Citizen role, but for many of the other roles it made sense to group the User Stories with all the rest.

Tip 4: Flipping roles: In some cases, you will encounter Stories that say one role cannot do something. I prefer to see it from the perspective of what a user can do. So, when you find one of these move it to the role that can do something and change it to a can version. When looking at a set of user requirements, it tends to only state what a user can do. What is interesting about the Constitution is that it talks a fair amount about what certain roles cannot do.

For example, Article 1, Section 10, Clause 1 is written as

“No State shall enter into any Treaty, Alliance, or Confederation; grant Letters of Marque and Reprisal; coin Money; emit Bills of Credit; make any Thing but gold and silver Coin a Tender in Payment of Debts; pass any Bill of Attainder, ex post facto Law, or Law impairing the Obligation of Contracts, or grant any Title of Nobility.”

There is a lot written in here, but you can see that no State shall coin tender. I prefer to write it as the following because it gives a little more detail as to why.

As a State I want Congress to have the sole power to coin money so that I don’t undermine the United States

Tip 5: Renaming: Don’t be afraid to rename a role. Sometimes there are two groups using the same name or during findings you realize that there is a much better name to use that is more natural or descriptive.

In the case of the Constitution, I wanted to rename “Indian” with “Native American” so that the vocabulary is updated to today’s conventions. As you build out your User Stories, keep an eye out for similar issues.

Step 3: Prioritizing the Stories

Typically, after this point I would have the Stories grouped and ordered. Then, we would do a meeting where we prioritize them into the most critical features, the next features, and the future features.  My preference is to do this with color. Typically, I make the most important features black, the second features blue, and the future features grey.

But the Constitution isn’t a software specification, and it has already been implemented. I suppose you could claim that everything before the Bill of Rights was the first version. Then all the amendments beyond the 11th are future features. However, it just doesn’t make as much sense when all of it is already implemented, and I am just analyzing it in retrospect. Priorities make sense for planning, not as much for analysis.


Deconstructing the Constitution into User Stories was a fun way to get a sense of how and why the United States government works the way it does. It helps to predict what could happen and to look for flaws. You can apply this technique for any situation where you have a complex requirements document or an unstructured set of ideas.

Whats next?

I can’t help but come up with some ideas while doing this task. For example, the Constitution only represents Constitutional Law. What if you used this same technique for Common Law and grew out all the rights of a Citizen? It would allow for someone to see what cases defined the rights they currently have.

Another idea is that I could repeat this process for a different government’s constitution and compare the differences. If you do this on a global scale, it would give a really interesting analysis of how citizens are viewed by their governments around the world.

If you have ideas, I’m happy to share the work I have done. Please email me at

10 Levels of incremental product development

BJJ_White_Belt.svg: Buddy23Lee derivative work: K21edgo (talk), Orange belt, Yellow belt, Black belt, Brown belt, Used it in combination with other works. by Matt Paulin, CC BY-SA 3.0

I have two kids, one in karate and one in gymnastics. Once a week I watch each one practice their sport. Competitive gymnastics uses leveling system that goes from 1 to 10. In karate, color belts represent different levels of skill, starting with white, ending in black, with several different colors in between.

In both cases stakeholders can quickly adjust their expectations about a person from this shorthand knowledge. Coaches and teachers know immediately what to expect from a participant and can see what the individual needs to work on to get to the next level.

I believe that product ideas can follow a similar road. In this article I’m going to propose a leveling system shorthand to help communicate the maturity of a product idea.


Level 1: Just an Idea

This is the back-of-a-cocktail-napkin level. We might be just talking, and the idea is in the range of: “Hey, you know what would be cool?” That’s a Level 1 idea. It’s a playful thing that can provoke more conversation and might seem valuable enough to write it down. No research, work, market studies, or design have gone into it. Most ideas stay at this level.


Level 2: Developed Idea

At this point I’d expect the idea has an elevator pitch, user stories, and key screens. The idea may have a pitch deck as well. Maybe not a super-polished, researched pitch deck, but at least a decent attempt at the Alliance of Angels criteria.

You can put together all of this work in under a week if you’re diligent. Although for our team, we seem to have several ideas under construction in tandem, and so we’re continuously updating them. What’s nice about Level 1 and 2 ideas is that they don’t require any real commitment. We’re still playing as we gather this information, and the concepts can be moved forward incrementally.

But you should notice that there’s a difference between Level 1 and 2 ideas: Anyone can conjure up a Level 1, but it takes time and to properly parse out a Level 2.


Level 3: You’ve Got an Internal Prototype

The next step is to try the idea. This is really an exercise in creativity. For a game, it might just be a stack of note cards and a spreadsheet. For a flying machine, it might be a model. The challenge here is to be resourceful and figure out a way to use the idea with the least amount of work. No one expects to release this prototype—it just needs to be enough to demonstrate the experience.

At this level, you get to be proud of writing the least amount of code or building your prototype  from junk around your house. Now you’ll likely spend several iterations adjusting your user stories, screen designs, and previous documents. The goal here is to determine the product design that you’re going to commit the time and money to release in a private beta.


Level 4: Private Beta

This is where you’ve actually built and released the product to friends and family. The idea needs criticism from people who are not as obsessed with it as you are. They need to be able to say things like: “Oh, I forgot to use it,” or “I didn’t log in because I didn’t want to create an account,” or “I really have no idea what I would do with that.” It’s this criticism that sends you back to your designs to adjust them and try again. To get past this level, the idea must be something somebody would actually use. Through your private beta, you should have an answer to this question.


Level 5: Public Release

Time to release your idea into the wild. Make sure you’ve added a way to track what people are doing with it and if it’s spreading anywhere. Whatever criticism you heard from friends in Level 4, you should expect it tenfold in Level 5. This is all about watching what people do with your idea and asking questions. If you’re an engineer, this is the point where it gets challenging. All the coding and technology puzzles are somewhat solved, and now it’s all about the users.

Until users are consistently using your product, you’re not past this level. It has to solve someone’s problem better than the way they’re currently solving it. So keep iterating and solving their issues to see if the idea can work its way to a market. Some activities you might be doing at this point are: trying ads to get into markets, interviewing users about the experience, and working on UI/UX issues where users are getting lost.


Level 6: You’ve Got Users

Someone is using your idea! Now you need lots of people to use it to qualify as an audience. Keep experimenting with different ways to connect to the audience and how more users  discover you. Common questions at this level are “Who is using this?” and “What are the alternatives?” and “How do you grow it faster?”

You need to set a realistic expectation for audience use, and that depends on the idea. Success could mean that 10,000 people have used it, 20 people have installed it, or 1 hospital is using it; it really depends on the idea and what “success” means to you. But if you’ve come this far, you’re doing well. From here you’ll continue to iterate and improve the features, experience, and marketing. Once you can define who these people are and how you find them, you're ready for the next level.


Level 7: You Know Your Audience

At this point you should be able to show that the audience is growing organically. Whatever strategy you’ve devised is working, and people are spreading it. Now your problem is growing the service in a way that doesn’t break everything.

This is what they call “a really nice problem to have.” But you have to figure out how you’re going to grow it before you actually grow it. I know many companies that ended up with legacy code that is very hard to extract because they grew too fast. A good place to start is to model how many people and what resources you will need to satisfy larger and larger audiences. Then focus on ironing out the wrinkles that slow the growth of the user base.


Level 8: Product is Scaling

Now users are on-boarding organically, and the system can keep up with it. This is exciting, but there’s a problem: You’re still paying for your idea. To truly test if it is valuable, you need to make money with it. Early on you created business models for how this can work. Perhaps you are selling something directly to users, maybe you will collect ad revenue, this could even be a business to business relationship. You must prove that your idea can generate the revenue that you predicted.

Once upon a time we created a game called Quirks. It was a simple game that we only released for free on the iPhone. We sort of forgot about it until I logged into iTunes and realized that we had several thousand users playing it every day. So we decided to charge $1 to install it. Immediately our usage dropped and I think we earned about $20 doing that. The reality was that our business model did not work and we should have released a paid version and carefully added features to make the game valuable enough for someone to pay for it.


Level 9: Validated Business Model

As the title suggests, if you’re at Level 9, your user base is growing and you’re on the way to profitability. You should have a great spreadsheet that shows how the whole thing will come together in a cash flow-positive way. Your tasks now are to continue to iterate and discover issues with your business model, all the while adjusting your product to fit what the market will handle.

Keep growing and scaling the business. Imagine yourself a gardener that is carefully watering and weeding around a plant. If you do everything right your spreadsheet model should fit your predictions and the whole business will balance itself out.


Level 10: Cash Flow Positive

Congratulations, you have a self-sustaining business. Now you have lots of problems that are good problems to have. Maybe you have too many customers, or you need cash to grow your idea, or other people want to steal it, or you need to hire more people. These are great problems to have, be thankful.



Here at Ministry of Product, we’ve got a lot of ideas floating around. We might put a month into one of them, here or there, but it’s often hard to compare them because they’re at different levels. This leveling system allows us to quickly explain how mature an idea is, so we can set our expectations accordingly, much like a coach or teacher does in gymnastics or karate.

These levels should help you to judge how far an idea has been grown as well. It gives you a realistic view of how far you really need to go to get your idea to a stable place. Product creation can be a long road, this is a good way to see how far you have gone.


House Building is not like Software Development


For several decades I have been involved in software; building software products for large companies, growing a startup, and even running a boutique consultancy for 10 years. I now do independent product development helping client turn ideas into software products.

Many times in my career I have heard software development described to a client the same way you would create a house. This metaphor made sense on the surface. A house is something that the clients could relate to. There’s a design phase where they talk about what they want, then there’s the building phase where the design is implemented.  

Does this metaphor sound familiar? It should, I have heard it from clients and other developers. But it is dangerous to use something so concrete to describe a medium as fluid as software. I now avoid using home construction as a metaphor for software development. Here’s why:


Scope can change dramatically after the contract is signed

As the client sees the product come together they reach realizations and will want to change the design. If we were building a house, it’s like the client casually mentioning that they want to add another bathroom on the second floor—right after you agreed on a price.

Unlike a house, software is made to be changed. Whereas a house is a largely static product, software needs the ability to adapt to changing demands, many of which present themselves during development. The catch is that clients cannot easily see all the work that goes into those changes, so they struggle to understand the complexity introduced with a new request.


Software processes can be complex

Building a house isn’t simple, but most people understand that first comes a design, and then you build it—that’s the process.

By contrast, software development can employ a number of flexible processes that many people aren’t familiar with. Processes like weekly stand-ups, sprints, backlogs, retrospectives give development teams the ability to quickly adjust to the changing needs to a project.

I find myself educating clients as fast as humanly possible, because without taking the time to explain how we change the software, and in-turn budget, the project would simply seize up.

The good news is that agile methodologies and the like are slowly permeating other industries and schools, but until these concepts gain wider acceptance, essential client education takes time and patience.


Cash flow will strain the client relationship.

If you apply for a construction loan, the bank wants to be sure of a few things before they’ll agree: like that you’ll pay them back, that the construction firm is legit, and that the costs of the project are reasonable. The bank won’t take the risk if any of these criteria don’t match what’s expected.

When all of these things do align, the process works well; the bank doles out money to the builder as costs build up. The builder knows that there is money, the client knows they will be spending it, and the bank controls this in the middle.

Software is nothing like that at all. To start, there’s no guarantee the client has any money, so it’s usually on the risk of the builder to pay their own people until the costs are covered. That can easily end up being 60 to 120 days depending on the terms of the agreement. It’s unfortunate, but right after a contract is agreed on, it’s a little like the developer—using their own funds— just extended credit to the client, all based on a handshake.

Sure, this can be solved by having the client pay up front. But there are always other firms willing to jump in to get the business, and the pressure is always there to just make a sale. As a development firm, it takes a lot of discipline to properly deal with the financing before the work gets started.


Estimates might be the biggest problem

In the middle of every project is the budget. For the construction industry they can get three bids from subcontractors and calculate material costs. My brother in law does this for hospitals in Missouri. As complex as this is it is fairly precise.

In contrast, for the software developer, this process is much more based on intuition and experience. Construction processes can base time and material costs on square footage, linear feet, volume, and other measurable metrics. Software lacks this hands on relationship. Estimates simply have to be summation of estimated risks. We have a couple techniques for this, but the process is wrought with variables. There are many places where this can be miscalculated. For example, the client might not have told you of everything they wanted, the developers might have misunderstood the requirements or the technology landscape can change while you are in the middle of creating the product.

These are the obvious things. Then add scope creep, legacy code, and code debt, and things can balloon quickly. If this estimate is wrong, there’s immediately a problem, and the longer that problem isn’t addressed, the bigger it’s going to be.

As developers, have ways to mitigate this, like doing development spikes to test technology and adding integrated tests to see if legacy code is usable, but in the end a number has to be agreed on, and you’ve got to do it quickly to start the project.


A better metaphor.

Let me propose farming is a better metaphor for software development.

It takes time to grow a crop, and there’s always the risk that it will fail due to weather, insects, and countless other external variables. It also takes time to grow a software product. Slowing things down increases the chances of success.

In my experience, It takes at least a month to just think through an idea. It takes at least another month to build a prototype that you can test internally, and it can easily take one to three months to produce a product that’s ready for release.

It is totally fair to say that a software product takes three to six months to grow, and at that point you basically have some young plants. It takes even more time to get it scaled up for a commercial release.

Sure there are magic fertilizers, ninja farmers, and amazing machines you can rent. But people need time to think, experience, and learn because that’s when ideas grow.

Don’t construct a house out of software, take the time to grow a product.

Incubator Retrospective


With the launch of our first internal product, , it seems like a good time to step back and review how this is going.

The backstory

Originally, I proposed how to build a self starting incubator from a consulting firm some years ago when I wrote this book. Then we tried it out with our startup zCrowd. That didn’t go so hot for several reasons, the obvious take away was it was too complicated. So we reformed as to try again.

Since January we have been working on building out one month size product. We have organized the ownership using the BS3 rules.

This is what we learned.

There are several stages

Originally I had thought we could just build something every month. Turns out there is more to it than that.

  1. It takes about one month to really think the idea through.

  2. It takes about one month to build an internal prototype.

  3. It takes about two month to build a production ready version.

I think we can get that last step down to one month. This means that we could potentially release 3 - 4 products a year at this cadence.



Just pick a name to start

Naming is hard. Pick something reasonable to name it for your internal team. But before you build the pro-version you will need the real name. You need to at least own a website to cross this threshold. Keep it simple though, just name it something descriptive so that you can get going and then keep a list somewhere of naming ideas while you play with it. Something eventually will bubble out.



One month size is perfect for building something.

Anything less and it feels too pressured, anything more and it felt like there was too much room for scope creep. This lets you focus on just one project for that month. Do note that you can be thinking through about three projects at once but we only build one at a time.



Journaling is important

Keep a document shared that you can add journal entries to. There is a chance you put this project away with nothing done. This at least leaves some account of what happened and what was learned.



Start with no goal but more of a desire

We didn’t know what was going to come out of the month except we were going to hang out. About half way through we had a much better idea of what we could accomplish. In both cases it was much smaller than what we were imagining. Everything always takes longer so as long as you can reduce your expectations you can fit it into a month.



Working alone is hard

If you buddy up then you feel like you have to accomplish some smaller goals between weeks. At least then you feel accountable.



We were not very consistent with meetings

It makes sense to set up the meeting ahead of time. Just so you can set the expectations of your spouse and friends.



The first phase is really the “Play Phase”.

Seems like the goal should be to get enough of the idea in place so you can play with it for the first time operating it. The second phase can then be more for a wider audience. If we keep that in mind then it is a bit easier to focus. We really just need to get far enough to share the idea.



Make user stories

Before you start, make a list of user stories just so you can have some idea of what needs to be accomplished. It is an easy way to get people on the same page and I found I immediately needed them as soon as the build was underway.



Make wireframes

It doesn’t take more than an hour and it helps to get your thoughts organized so that everyone can see what we are talking about.



Set measurable goals

Make sure each week you state what you are going to get done by next week. It seemed like there were several weeks when things didn’t get done.



Save a day for your projects

It’s easy to overbook client work but that means you aren’t doing any of your own stuff. It is a constant battle to try and give clients what they want, have a good work life balance and then save some time for yourself. We set aside a day a week for this sort of thing.


Overall this process is working well. We find ourselves talking about the next month projects while also getting excited about this month. My sense is that if we keep making the initial projects some of them will keep us excited enough to merit a next month.

If you find yourself organizing the same thing, please tell me how your incubator is doing. What have you learned or done differently?

Structured Conversations


Too Much Noise

There is a problem with comments on the internet. We can write anything, in any form, in any way we want. The reason this is a problem is that it can be hard to keep on the topic and have the conversation get to anything useful.

People distract, people use fallacies, they change the topic, they avoid sensitive topics, they interrupt because they want attention. This is just people and it prevents us from every getting to something of value in a conversation.

The problem gets worse when there are lots of us. Like at a meeting, or on matters of politics where we want to be heard.

Here at MoP we have been thinking about this a lot over the last couple months. What we want to introduce is a concept we are calling a structured conversation. You have seen this before. They are used in therapy with I Messages. In software engineering we have User Stories. As a kid you might have used Mad Libs. The trick is in limiting what we can say into a form that pushes the conversation forward.

You might ask, why is this important?

After we started thinking along these lines we have realized how powerful this can be in a group setting. Different patterns can be used to achieve different effects from a group; entertain, create, debate, and decide. But it all came down to the simple act of planning out how to setup the conversation and to find a way to visualize the end result.

Really this article is just a teaser for what we are working on in the background. Stay tuned as we release several products to toy with these concepts.

In the meantime, maybe you see patterns of conversation that are successful in helping teams focus? I would always be interested in these so feel free to contact us.

User stories are not the hip way to write requirements.

Screen Shot 2017-07-23 at 6.57.50 AM.png

Managers that don’t understand user stories write them like this.

  1. As a user I want to choose my engagement mode so that I can listen to the radio, explore or plan trips, or travel.

  2. As a user I want the app to remember my mode and state so that when I background or relaunch the app I see the same screen as the last time I used it.

  3. As a user I want the app to have a consistent branding and experience across all the channels, follow user experience and implementation best practices described in the heuristic evaluation, and leverage the appropriate interaction/visual design paradigms for each channel so that the app and website are performant, intuitive, and delightful on iOS and Android devices as well as desktop browsers.

  4. As a user I want the app size to be 100 MB so that it is compatible with iOS OTA downloading footprint size limits for cellular installations.

  5. As a user I want the app to be mindful of data and processor/memory usage, utilize data compression and other efficient downloading/caching/backgrounding strategies, and have graceful degradation features so that the app doesn’t exceed the average cellular data plan or drain the device’s battery and also has good performance and audio quality regardless of my network type or connection strength.

Capturing a vision is hard. For folks that operate in the abstract a conversation might be enough. For more concrete personalities it feels like we should explain exactly what is desired so that it is written down with precision. Somewhere in the middle of this spectrum exist enough information to get to the next meeting. For me that is the user story.

The magic of agile development is iterations. We are not going to have just one meeting where the requirements are handed down and then the engineers build what was specified. Instead we are going to have one meeting to decide what is going to be built and when those first user stories are going to be completed. Then there will be a show and tell and we will go through this process again.

To write good user stories it is good to think about it with the INVEST mnemonic created by Bill Wake. 

Independent : Is the story dependent on another story?

Negotiable : Can you push back on this story and discuss it with the business owners?

Valuable : Does the story provide value to the stakeholder?

Estimable : Can you estimate how many days you can do this story?

Small : Can you break the story into multiple stories until it fits an agreed on minimum size?

Testable : How are you going to test that this story was completed?

If you look back at the original stories I started this article with you can see that there are many of these questions that cannot be answered and therefor they need to be rewritten.

I think what really stands out for me is that these stories are written from what the manager wanted and not from what the customer wanted. This is a very easy mistake to make. It requires discipline to remember that the product is being built for a customer and each story needs to focus on what the user wants and why.

Requirements documents kill creativity and slow the product design. They make the assumption that we already know everything we are going to know and can therefore decide all of these things now. It’s easy to get into the mindset where you just tell them what you want and expect that to be what they build. But, software has gotten faster to rewrite and that changeability is what makes it so powerful. In software, it changes overnight so only plan one sprint at a time because you never know what will happen next.

Kevin's Refactoring Kata

How to fix that old software.

Have you ever rewritten code from another developer? It is an exhausting and painfully frustrating battle. If you do everything right, then it looks like nothing changed. It usually involved lots of wandering around the code only to find that they are tracking state in the an obscure variable. At some point you just want to throw the whole thing out. 


My friend Kevin approaches software development unlike any other developer I have ever met. He does an amazing job rewriting old code and repairing old systems. I took it upon myself to study what he is doing because it is so very powerful and useful. What I realized is that it is a repeatable set of steps. Like a martial art kata. If you can master this way of thinking you can make incremental improvements on your software one test at a time. This allows you to incrementally make it a well tested, easy to reason about system, that is much more maintainable for the life of the software.

Kevin’s Refactoring Kata

Step 1: Look at the system or component as a whole and regroup the functionality.

Step 2: Let each of your new components do one thing and do it well.

Step 3: Write your tests first describing all the behaviors you know it will need.

Step 4: Write your code new and use the old code as a reference.

Step 5: Get all the test to work.

Step 6: Swap it out.


Now to elaborate

Step 1: Look at the system or component as a whole and regroup the functionality.

First identify what the code is doing and what the behavior is suppose to be. This can be tricky because software sometimes has become entwined with other components and behaviors. For instance, they might be using a column in a database to represent state that triggers something else in the system. The advice here is to keep getting smaller until you can actually identify a component. Start with that. If you are unsure, start somewhere else. With every tests it will become easier to sort out what is going on.

Step 2: Let each of your new components do one thing and do it well.

This is based on the S “Single responsibility” in SOLID. It helps to start by naming the new component better. Try to name it things like CheckinService or CheckInController. Not something so vague like UserManager. In fact, try never to name it “Manager” or “Util”. These tend to create software with overloaded functionality. It’s like the box in the garage called “Misc” which is full of all the random bits that you don’t know where else to put them. Once you have your name then it is easier to make sure you know what it does.

 Step 3: Write your tests first describing all the behaviors you know it will need.

In this step just think through what this component does. Does it add more users? Does it make sure that users have a special permission? What does it do if given a bad user? Just list all of these as if they are tests. Make sure these test don’t cause it to fail but simply list the behaviors you are expecting.

 Step 4: Write your code new and use the old code as a reference.

Make your new component alongside the old chunk of code. Then start with the first test and write it. It should fail!  Now go add some code to the new component until it doesn’t. Keep going though this loop adding tests and behaviors until this one component is well defined. When you get stuck you can use the old code as a reference to understand what the previous system did. 

Step 5: Get all the test to work

Don’t stop until you have finished the tests. What is great about this approach is that you don't have to do it all at once. If you have to take a break leave yourself a broken test so you know where to start when you get back to it. You should be able to get a test created and solved in a fairly routine way. Each one gets you closer to being done. If you find yourself feeling discouraged, just run your tests again and you can see how far you have come. It’s small but it does make you realize that you are chipping away at it.

Step 6: Swap it out

Now you get to switch your code in for the old code. After you have proven you that the system as a whole works, you get to DELETE THE OLD CODE. That really is the best part.


To conclude

I know this seems obvious when you write it this way but it is so very very easy to find yourself on an endless adventure unraveling other developers super clever ideas.  They took shortcuts, they wanted to show how brilliant they are, they didn’t make it easy to understand. By following through on these steps you are on your way to a much easier to maintain system.

What is Product Development?

What is Product Development?


To me, this means the art of turning an idea into something people want. An idea is a solution. But, if the problem it is solving isn’t big enough then it will not live. In order for it to be alive, it must have both an audience and the technology to support it. I am focused on mastering this processes of build, measure, learn to turn ideas into sustainable businesses. The important notion here is iterations. Everything happens in a circle, not a line. The process repeats until it works or until the team and resources have reached a limit.

I like to set the iteration limit to three. This is arbitrary and could be more or less. The important notion here is that three iterations sets my team's expectations. No one shows up expecting to nail it the first time. It also protects us from the Sunk Cost Fallacy. This is when you reason that further investment is necessary simply because the resources already invested will be lost. It is a nostalgic position and is dangerous because it uses your time and money on ideas that have been tried thus stunting the other ideas that you haven’t tried yet. This is the balance between sunk costs and opportunity costs.

I also believe strongly in giving yourself some time to play with an idea. Especially in the early iterations. The first iteration could very well be just building the idea so that only you can play with it. Then at least you can see if it was worth it. A common mistake is to believe your idea will be successful before you have tried it.

Product Development is a system of limits.  Here are a few...

  1. Journal as you go.

  2. Write down your assumptions early and do a retrospective later to evaluate them.

  3. Keep your first build iterations to month size projects

  4. Build the simplest thing that could possible work first.

  5. Give yourself three iterations

  6. Build then operate.

The trick to this process is in the limitations. Keep the first build as small as possible to learn as much as possible. The Ministry of Product is a Dojo of sorts for helping to explore this. I am constantly learning new ways of thinking and new ideas. This practice will never really be finished. We can only hope to continue the practice so that each of us can learn from the other and ultimately discover real paths that no one has ever taken.

We are MoP

What is the Ministry of Product?

The Ministry of Product is a community of talented developers, designers, and innovators who are passionate about the art-form of product creation. It is somewhere between an incubator and a self help group. Ultimately it boils down to a trello board, a slack channel, and some really great people.

Who is on in this group?

I limited the community to people that I have worked with in the past that I feel are genuine, dedicated, and passionate about their craft. I need to have worked on a project with you at one point to get a sense of this. Seeing how someone reacts when things aren’t going their way is part of the process.

How does it work?

Anyone can contribute a month sized project to the group so that others know what is in the backlog and can choose to participate.  It needs to have the following.

  1. A name that you have decided on and purchased a URL for.

  2. A goal that can be accomplished in one month. This should be enough to put in front of some end users and start to gather feedback.

  3. Make a card on our trello board and tell folks about it on slack.


Who owns the products?

If you build a project with us you need to use the Big Slice Small Slice (BS3) rules. This means that you are planning for multiple product build iterations with a period of operating it in the middle. If this isn’t what you are doing, you need to be very clear about that up front. My recommendations are to use BS3 to get the product to the point you are making money with the product and then everyone who is going to be part of it to still have a 3 year commitment to the project once the company launches.  Organize this as a share buyback.


Does MoP get a stake in every project?

NO, absolutely not. It is a facilitator and requires nothing from any of the members that they don’t want to freely contribute. Ownership comes from participation, so unless MoP is helping then there are no expectations.

The Month Size Project

The Month Size Project

How much time should you budget for getting your first MVP together? I think a weekend is a bit absurd, but on the other end of the spectrum you don’t want to take a year.  In the spirit of release early and often, I propose that you fit it into a month.

The Month Size Project doesn’t need to be all that intimidating. What it is intended for is to get you and your team to force your dream into a month size box. The art is in the limitations and in this case they are self imposed.

Building up to that month, it is totally OK to be thinking and laying out the groundwork. In fact it is encourages just to build some excitement; Talk to people, draw screens, research your audience. All of these help to get it going.  Then when the month arrives you and your team should already know what they are suppose to be doing and what the tools are they are using.

Before the month checklist

  • Figure out who is on your team.
  • Name your product and buy it’s website if you need one.
  • Figure out your technology stack.
  • Do some tutorials with the technology you haven’t used before.
  • Buy any services and set up accounts.
  • Map out the architecture and calls using sequence diagrams.
  • Draw your screens and get your art assets figured out.
  • Plan out times and places to meet.

During the month.

  • Set week long sprints and deploy something every week.
  • Stop doing all that other stuff you do so this gets done.
  • Block out time to work together and independently.
  • Track how much time everyone uses so you can apply it to the first BS3 slice for ownership.


Does it have to be a whole month?

No, this is a way of time boxing it together. If you can build something that you can learn something from in a smaller amount of time then do it. This is more of a tool for getting focused when you have too many ideas and tangental things going on; kids, job, etc.

Where does this fit into the BS3 rules?

This is the first development slice.

What if you need more time?

Then you didn’t trim your scope down enough or put enough time into it. Do a retrospective with your team and ask what you could have not built. Remember it is a learning experience.

How do you divide up a company before it's a company?


If you build something with a team, then this topic comes up.  Heck it comes up when you are just thinking about it. It’s the first test and sometimes the fast end to an idea.

How much do I get? How much do you get?

The faster you can get past this the better. It is the most important conversation you should have. However, it is the most stressful conversation you can have with your team as you divide nothing up between each other. The following is my idea for how you can get past this issue quickly.

BS3 rules (Big Slice, Small Slice)

Think about it like a pie chart. 4% goes to the person who originated the idea. (Yes, seriously, get over yourself it is a good idea but it isn't a company). Then split it into 3 phases. Each phase consist of building an MVP and then operating it to see if you have found a market. If in three phases you haven’t found a product market fit then it is time to call it.

  1. Phase 1 will have 16% portion for building it and 16% for operating it.

  2. Phase 2 will have 16% portion for building it and 16% for operating it.

  3. Phase 3 will have 16% portion for building it and 16% for operating it.

Now go make a spreadsheet like this.

SliceValueContributor 1Contributor 2
Original Idea4%
Phase 1 Building16%
Phase 1 Operating16%
Phase 2 Building16%
Phase 2 Operating16%
Phase 3 Building16%
Phase 3 Operating16%

The idea is that you have budgeted these specific 7 activities as the "big slices" of the entire project. What you are going to do is track who contributes to each big slice so that you can figure out their "small slice". Over time those columns under the contributors names will turn into the percentages.  The end result is a dynamically created ownership model.  

Allocating the small slices

For this part you have to change your thinking so that you represent both the company and your own interest at the same time. As the company, what are you willing to pay the contributors to put some effort into this?  Is it $100/hour?  Is it $4000 as a fixed amount? Figure that out between each of you for each phase. This is the deal you have with the company. 

What you are going to do is track these costs every month and tally it up for that slice. At the end you will have something like this.

Phase 1 BuildingContributor 1Contributor 2Contributor 3Total
Time contributed60 hours40 hours
Value Contributed$6000$2400$4000$12400
Slice Percentage48%20%32%100%
Slice of this slice7.6%3%5.4%16%

When this phase is over, go back and update that first spreadsheet.

SliceValueContributor 2Contributor 2Contributor 3
Original Idea4%4%
Phase 1 Building16%7.6%3%5.4%
Phase 1 Operating16%
Phase 2 Building16%
Phase 2 Operating16%
Phase 3 Building16%
Phase 3 Operating16%


If you didn't notice, this gives you the ability to add and remove team members easily. It gives you the ability to budget. It also gives you an idea of how much effort you have put into this so when you are negotiating with your first investor you have a clue of what you have done.

What you are really doing with this model is making up a new currency and then spending it with each other. It is what you will be doing when you raise money. But at that point it is more serious and your board will have something to say. 

Remember, the goal of this process is to get you to product market fit without raising capital. It is designed to give you a shot at testing your market three times and to pivot at least twice. You can of course extend the number of phases by following the same pattern.

Questions that have come up.

Why do I want to budget for three MVP?

You are about to form a team and find out if they are dedicated. Some will be and some won’t. It’s surprising when you look at pedigree and what people say about themselves, then you actually work on a project with them and find out what really is in their heart. You find the cynic working long hours while the ivory tower phd guy doesn’t really do anything. This process lets you set expectations for not just the people you start with but also for the people you end with. You can of course do it the other way but you will be having a lot of conversations about delusion as you have to constantly ratchet down expectations. From experience it isn’t fun to tell tell people that their 30% stake is now worth 15%. However if you start out telling them it was only 15% it is way easier.

What if this only takes one phase?

Then delete the lines for the next two phases and equalize the percentages. In this case the idea would still be worth only 4% but the first phase is worth 96%.  If you have to add a 4th phase it is the same idea. The general principal is that the idea is fixed value and the phases all have equivalent value.

Do we do this for the whole life of the company?

No, as soon as money is involved stop doing this and file it as a normal company. You can take whatever percentages you ended up at and normalize it to figure out the founders shares for filling the company as a C-Corp. 

This event might be raising capital or even better, finding enough revenue to power the company.

Can you put in real money?

Sure, as long as you and the company can agree on the 1 to 1 conversion. You might want to do this so that other contributors can buy someone else’s shares. You might want everyone to pitch in right at the beginning so that there is some capital for tools or resources.

How much time should we expect to take to build the product?

I think at a minimum you should expect 1 year to get through three phases. The max is 4 years because by then you will be absolutely sick of this idea.  But, as a team make that decision so that everyone’s expectations are the same.

Should we file something?

No, don’t make this official until the last responsible moment. Appoint someone trustable as the treasurer to handle any money contributions. This really can be just a spreadsheet to keep score.

What if we already have been building this?

Then decide what phase you are in. Most likely it is the first building phase. So just argue out how much everyone has contributed to that point. That still leaves a lot of pie left.

What do you mean by “the faster you get past this the better”? This conversation is super important and needs time to sink in for everyone.

Your biggest priority is finding product market fit. The more time you spend arguing over how much everyone gets the less time you are spending attacking the problem of creating value. This process is designed to involve contributors, see if they are worth their salt, and to get to that product market fit fast. It’s a framework for setting expectations. By simply agreeing to use a process like this you have gotten on the same page and are moving forward. The raw reality is that you will be earning your percentage which ends the debate of who is more important pretty quickly.

Is this for getting to an MVP?

No, it is for budgeting out three MVP’s in advance. You should think of it this way because you don’t know what you don’t know yet. If you are successful in the first attempt then great, ignore the later phases. I also admire your confidence.

Who is governing this process if there isn’t anything formal in place?

These rules are designed to keep the focus on finding the product market fit and setting expectations of everyone who has contributed. They should be enough to get you to that point. It will be evident who is a founder and who just wanted to have some experience. When money starts to get involved you will need to say who the founders are but I bet this will be obvious and you don’t need a process for figuring it out.

Is this an alternative to the traditional process of creating a startup?

It seems like the start story is 2-3 people work hard in a garage after hours to build a prototype and learn something special. They then raise capital, grow a company, and either IPO or get bought to have an amazing exit.
I don’t know any of these people. I know lots of brilliant middle age engineers that have families and can’t risk that. They all have clever ways to solve problems and a limited amount of time to devote toward a dream. This is for that type of person. It is possible to build and sell something without putting your family at risk.



Now go build something so you have a reason to be arguing about this.



Zen Master Kevin

Building something? Working as a team? Use these Kevin-isms to keep each other efficient, tested, and moving forward. 

I have this friend “Kevin” who has mastered how to get teams to self organize and think without being lead.  He does it with questions which he pulled from the socratic method and bits of wisdom he has collected over his career coaching and writing software.

While you are building out your dream, and you come to a point where a decision is needing to be made. Try these questions and helpful rules of thumb to simplify and get it done.

What’s the simplest thing that could possibly work?

Yes, there are some awesome things you can build and wouldn’t that be great. But you need to get it built first. What is the least you need to do?

Why not both?

Sometimes debates come down to two competing ideas, why can’t you build both of them? This question helps you figure out the argument that separates them.

How do you make this easy to reason about?

At some point you won’t remember why you build this or someone else will have to figure this out. Remove dependencies to make it easier to reason about.

Deleted code is tested code.

This saying makes you feel better when you chop away something you just spent the last week building.

Deploy early and often.

Un-deployed code has no value. If you got it built, get it out there so someone can use it.

Leave ideas in code as comments, not as features

It’s easy to suddenly have a brilliant idea, if you have to put it somewhere in the code, make a comment not a new function. Come back to it later if you still think it's awesome.

All decisions eventually become regrettable.

Don’t get hung up on debates, eventually you will learn something that unravels the original reasoning. Leaving test to document behavior and making your code easy to reason about will make it easier to change later.

Don’t build today what you can put off until tomorrow.

Be disciplined, every line of code you add is a line you have to test. So don't waste all that effort making code that isn't going to add business value.  Wait until the "last responsible moment" to add new code because that is when you will the most.

If you care, you will test it.

Tests are your chance to explain the desired behavior, this is the only way to know if you are done. Test that are being run regularly are the only real documentation of your code and project.

Build first if you are prototyping, test first if you are going to use it.

Testing first is super hard right at the beginning when you are still trying to get off the ground. But after you get something to work, start figuring out how you are going to test it.



Don’t code alone.

Buddy up, it keeps you from wasting time in a creative haze. Paired programming and pull requests will help you fight the battle against technical debt.

Make it work, make it pretty, make it fast.

Sage introduced me to this saying.  I think he actually butchered it a little but I like his version better. Looks like the source was the Unix programmer Kent Beck.

This is the simplified mantra for getting some code done. It is easy enough to remember and yet still helps as a guiding principal.

For me the reason this is so powerful is that there are a lot of competing philosophies. We are working with a medium that can do anything. By that I mean software. Given a little bit of time and some code you can make virtual worlds, control cars, control phone, or you can just keep writing todo lists in every programming language imaginable.  It is quite an overwhelming experience really. If you have all this power at your fingertips then what stops you from doing something amazing? What comes out is that it is your own personal limitations that keep you from being amazing.

I don’t think this is entirely fair since the ability to create has been amplified by technology. So don’t underestimate the effect that has on a person. It is probably like that of an author with writer's block staring at his typewriter thinking, “I can create any world on this white paper, so what is wrong with me, think, think, think, think….”

In software land you get that “analysis paralysis” and that bubbles into the imposter syndrome. As a developer it is easy to get caught up in the epic amounts of code, languages, and philosophies. A simple mantra like this is almost a beacon of light that helps you cut through the fog and get on with something.

Start with what will work. Ask yourself the questions “What is the simplest thing you could do that could possibly work?” then time box that and do it. Maybe try out the Pomodoro Technique which is just a fancy way of saying set an oven timer. That will help you focus past the first part.

After that make a test and prove that what you wrote works.  Yes, yes, yes, I know in true TDD you should write the test first. But, when you need to feel like you are moving forward I would advise you write from your heart. If you feel a boost of encouragement from seeing code work do that first. Of course you are a good developer and you will switch to the TDD approach but at the beginning of the project when nothing is written it is more important to feel joy because that is the only thing that is going to push you forward. Apathy is your biggest enemy so build what excites you first.

Once you get that bit of code and it has a way for a user to interact, look at it as a designer and try to figure out what you can remove from the UI you just created. Go reductionist and question everything. Show it to people and see how they use it. This is the “make it pretty phase”.

Finally, you are going to need to make it work fast and that is when the real puzzle solving engineering brain kicks in. Build your services, your load balancers, use map reduce. Just don’t try to do this first. Donald Knuth said “Preemptive Optimization is the root of all evil”, I agree with this so do it last if you ever do it at all.

Your company is made of meetings.

Meetings provide the structure for your company. With the right set of meetings, the right people end up talking to each other, decisions are made at the right level, and the organization learns and adapts.

HOWEVER… I have hardly ever seen it work this way.  I’m not sure if there is something called “meeting debt” but these were some of the reasons I was called to a meeting.

  1. Meetings feel productive without doing any work.
  2. At the end of the day you can say you did something, you went to a meeting.
  3. Everyone gets to be involved!
  4. Now no one feels left out because they all got to be there when things were decided.
  5. The head person gets to feel important! 
  6. It’s what we do on Tuesday!
  7. We have had this meeting forever.  Let’s not rock the boat.

These are not good reasons for a meeting. They are good reasons to justify a paycheck.  


Problems with meetings

Meeting get in the way of getting things done.

At some point somebody has to make the doughnuts around there and do the things that were expected from the last meeting. Meeting during the day mean that these folks have to work in the off hours.

Meetings are expensive.

As a business owner I would look around the room and realize that if you have 10 people at a meeting and you are paying them $100/hour then that meeting cost $1000 dollars. Most people don’t look at it this way but for the sake of the company you should.

There are smarter ways to communicate

Face to face is super effective for difficult decisions or when judgements about character are involved. They are not necessary for everything. There are countless ways to communicate which could be better.

Meetings get less effective with more people

The quiet people don’t talk when there are lots of people in the room. So if you are trying to make a classroom then you could have succeeded. Sometimes the quiet people have the best ideas. If you haven’t talked to them or figured out how to get them to talk then you can’t really argue they don’t.  Meetings don’t really pull them out of their shell. It just makes it more akward.


When you design your company’s org structure, design the meetings. This is where groups that wouldn’t normally interact need to be talking. You can use meeting to keep information from getting siloed.

  1. Design the meetings to change.
  2. If people don’t think the meeting is creating value, cancel it.
  3. If you have too many people, split the meeting. Can it be two groups?  Would that get more value out of everyone?
  4. Have retrospective meetings: This is where the company learns.
  5. Document the meeting and share that with everyone.

It really needs to be everyone’s job to write down what they got out of the meeting. Usually it makes sense to have one person take notes but let everyone add to it. Title it with a date and list who was there and why. If you don’t write it into the collective memory of the org then this was a waste of time. My favorite way to do this is to put it in a google doc so people can add to it and comment on points.