One of the most common problems I’ve encountered throughout my career has been miscommunication. Unfortunately, issues surrounding miscommunication are usually never resolved in a great way. I’ve seen it often take take the direction of finding someone to blame. Or, it’s swept underneath the rug and everyone forgets about it. 

Over the past week or so we started having some communication issues on our team. After talking with several team members it was clear that there would be something that any single person could do to help. Rather than badgering everyone else about how they were going to help I decided to take a different approach. I was going to hold myself responsible for what I could take action on and let everyone on the team know that I was doing it. So I sent the following email to the team:

Hey everyone,

Over the past several weeks we’ve had a few communication issues. After talking with a few of you it’s very clear to me that I can and should improve my communication.
Most of the issues I’ve discovered have stemmed from the agile (and loose) method we take in building products together. (And have mainly made Hans’ life more difficult - sorry!)
I think that the benefits we see from this agile method (time to execution, flexibility, and team building) are amazing and we shouldn’t abandon this approach.
But I do think we can make it better. So I wanted to share with you what I’m doing so you know what to expect and can also help improve the process.
  • Communication of project definition will happen mostly via email and will always include the entire group. 
  • This doesn’t mean that email will be the only way we communicate project definition, but it does mean that all new definition or changes to definition should be summarized and sent to the group via email to provide clarity, and transparency.
  • I will check in more often for feature updates. We can think of these as feature stand-ups that can occur in person or digitally. 
  • This will help us get ahead of miscommunication and keep us aligned through the product lifecycle. 
I’m confident that in a few days we’ll see the benefits of these changes. But, if they’re not working it’s important that we identify that so that we can act immediately and figure out what we need to change. 
I encourage you to share any thoughts or ideas you might have. I also want to thank you for helping me identify these issues and work towards improvements. How we work together is critical to our success and development as a team and business. Let’s never stop getting better.
I hope that this email will help alleviate our team’s concerns around communication and help us improve. But only time will tell. If you have any comments on how I handled this situation, feel free to tell me your thoughts in the comments below. I’m curious to know what they are. 

I came across this tweet from Chris Anderson today.

It might appear rather mundane at first. It’s a new expansion board for the OpenSprinkler that supports up to 16 stations. Think of how many plants, grass, and home-grown crops a 16 station sprinkler system can cover. How does that not get you excited?! Okay, I can see why. 

But what’s truly exciting about OpenSprinkler is that it’s open source. Want to buy it completely assembled and start using it straight out of the box? You can do that.

Interested in the experience of putting it together yourself? That’s available too. 

Finally, do you want to build it from the ground up and tweak it to your very specific needs? All the software and hardware files are available on Github (right here) for you to tinker with.

OpenSprinkler is a true open source product and that’s why I found Chris’ tweet so exciting.

The maker movement and advances in technology have certainly helped open sourced hardware (and products) gain momentum. I can only hope that as technology continues to enable access to more production methods that open source products become the norm. 

The past several days I’ve been working with Raphael (another PM at Shapeways) on a nuanced and tight problem. At the end of one of our meetings we generally would leave with a lot more questions than answers, often refuting some of our own beliefs and theories. Today wasn’t any different, but it felt different.

I had made the remark that the problem felt real today. We’ve been wrong so often about the problem that we didn’t even really know how to talk about it. I at the very least felt like a bumbling fool trying to explain what we were doing. And then it finally hit me, of course I didn’t know how to talk about it, I was wrong.

Being right isn’t about knowing exactly what to do. It’s most often about how the process of determining if you’re right. Throughout the process you end up being wrong, a lot. You don’t have any of the answers just yet. But, you also understand the problem in a way that you wouldn’t have otherwise, and that’s what will help you be right. In the end you’re always wrong before you’re right.

Every month I reset my password. If I had to guess I’d say I reset my password at least five times a month across different online services. The experience for the most part is fairly common. I select the ‘Forgot Password’ or “Help Logging In’ links and follow the instructions.

I’m always surprised when the experience is lacking. Whether it be unclear instructions, emails that take too long, or answers to questions I don’t remember preventing me from continuing, the experience isn’t quite as good as the rest of the product.

With technology becoming more accessible, it’s easier than ever to build applications and online services. Every week I find myself registering for a new one. It would seem impossible to expect anyone to remember so many different passwords for every account (unless you use 1password). Yet ‘Forgot Password’ has remained the same.

Forgot Password is just one of the important forgotten features. I’m sure there are plenty more. It’s important we remember, our product isn’t just what you want our audience to see, it’s also what they’ll have to see. 

Earlier this week I read Balaji Srinivasan’s post on why a16z is investing (betting) on Omada Health - you can read it here. Here’s an excerpt that describes Prevent, the unique product Omada has built:

Omada has built one of the very first digital therapeutics: a clinically validated, peer-reviewed, reproducible, and scalable way for people to treat a condition over an internet connection. Specifically, Omada’s Prevent product is a clever combination of science, software, design, and hardware, which blends the online and offline to achieve clinically meaningful behavior change. 

The post goes into great detail about the problem, the solution Omada hs built, and their results. It’s also a great example of how mixing online and offline can create a truly pervasive experience - something I’m particularly interested in. 

I know I know. This is the second time this week that I’ve written about Game of Phones. But I just can’t help it. If you didn’t read my post earlier this week then I suggest you do - you can read it here.

I met with Sam and Luke today and they gave me my very own limited edition Game of Phones prototype pack (#5/50)

They also told me that they launched their Kickstarter. You can check out their Kickstarter video below. So I wanted to share it with all of you and ask for your help in supporting Sam and Luke. 

I’m a huge fan of their game. It’s incredibly fun and accessible to everyone. But I’m also huge fan of the reason the game exists, and that’s the Entrepreneur Designers class taught by Gary Chou (and others) at SVA. As part of the class the students must participate in a $1,000 project. Here’s a brief description of the project: 

Make $1,000 of profit on the Internet in a reasonably repeatable fashion. Your project should be legal.  You may not rent out your bedroom or perform time-based labor.  Profit is defined as revenue minus hard expenses incurred, excluding time spent.

I love this type of experience based class. In my opinion students learn so much more from doing than regurgitating back information. So if you can, support Game of Phones - and if you can’t then at the very least share it with your friends. I promise you they’ll love it.

I spent most of today mining data, interpreting data, and talking about data. It’s one of my favorite things to do. I love the research process that points to or validates the right solution.

It’s something that I don’t get to often do anymore. But today, for four to five hours I didn’t accept any meeting requests, I didn’t hop on Skype or email - I just spent time in SQL and Excel. It was a blast.

It’s important to break away from what you do day to day. For me, it changes my mood, how I feel, and ultimately makes me a better person to be around. But I can go for long periods of time forgetting to break away from my daily routine. I should remember to break away from it more often. I’m better for it.

A couple of months ago Gary asked if I would be an advisor for SVA students in his Entrepreneur Designers class. It was a great time and I got to talk to people behind three really great projects. One of the projects I did an advisor session for was Game of Phones, a card game by Sam and Luke.

Game of Phones is described as “a new kind of card game where your smartphone skills win you points and stuff.” The idea for the game came from Luke and Sam thinking about how to make the “anti-social” device more social. What they came up with is a card game you play with people using your phone. It works incredibly well. 

When I met with Luke and Sam, I was really impressed with how much they had already accomplished. They had the first version of their product (which I am proud to say I own and have played since them), had done several play testing sessions, and were working out distribution strategy and logistics. 

A few days ago Sam posted a sneak peak on his tumblr samwander a sneak peek of the prototype cards. You can take a look at a video of the unboxing below. 

Today, Sam and I made plans to grab coffee on Friday. I’m pretty sure I’ll be getting a prototype deck of Game of Phones and I couldn’t be more excited.

Sam and Luke are planning on launching a Kickstarter for Game of Phones soon and I can’t wait to support them. If you’re interested in Game of Phones and want to support Sam and Luke on their endeavor you can sign up for email updates here

The past two days I found myself talking about how I manage disagreements - specifically around product decisions. But I feel this could apply most disagreements. 

Usually in the heat of a disagreement neither party can step away and ask “What are we arguing about?” This is always the problem. Everyone gets too wrapped up into being right, that you forget what you’re even arguing. 

When I’ve found myself in these scenarios I find that it’s best to ask questions such as: 

  • What problem are we trying to solve? 
  • What is the goal we’re trying to achieve? 

Usually I find that the people who are in the heat of a disagreement actually agree on the answers to these questions. And if they don’t, then that’s a great place to reset the conversation from. 

Once everyone involved in the disagreement can agree on the fundamental questions, it makes it easier to discuss the issues that are present and discover what the disagreement is about. 

In my experience most of the time the disagreement is about a difference of opinion. And when the parties involved can’t concede their opinion I think there are two possible resolutions: 

  1. The leader of the decision moves forward without unanimous consensus. This isn’t a bad thing. Sometimes a consensus can’t be reached and those who don’t agree will have to disagree and commit. 
  2. A third party objective “referee” is brought in to make a decision. This can be a great way for everyone involved to feel that it was a fair process and decision. 

It’s impossible for everyone to agree all of the time. We all have different perspectives. But, it isn’t impossible to get better at disagreeing. I hope this helps you disagree more efficiently. 

I always hear prioritization talked about with regards to effort and impact. It’s not uncommon for a team to decide what they work on based on effort and impact. Generally, I think that it’s a decent framework to think about the work that should be done.

The graph below is commonly used to plot ideas, projects, and tasks and decide which should be worked on based on the levels of impact and effort. Taking a look at the graph it would seem that all ideas and tasks in the top left quadrant should be acted upon immediately. 

But the problem with this chart, is that it doesn’t frame or set the context for the impact. Imagine that the impact was different for each point. This makes it harder for your team to build momentum behind their efforts. It also makes it harder for your stakeholders to feel the momentum of your efforts and get a clear understanding of what’s important right now. After all, you just focused on three completely different areas. 

I’m not saying that high impact and low effort projects, tasks, or ideas shouldn’t get done. There’s clearly benefit to achieving these types of tasks. But, I do think it’s important to build focus and momentum through prioritization by being able to set the context of the impact. Often times I feel that this is easily overlooked.