When working with a new team or facing a new problem, I never say how it needs to be done. Rather, I form one
question that the team needs to focus on. Answering this question helps the team keep focus on what’s truly important.
For example, working with a development team that is now dealing with a significant increase of customer complaints. First, do your homework. What are the complaints, is there a trend, is there one set of users that is experiencing the problem, just a basic understanding of the situation. Then you need to set some guidelines for the team. “If we were going to solve this…”
When the team starts to go off track, get them to re-focus on answering the question. They can refine the question, improve on it, but not ignore it or set it aside.
I’ve rarely seen this fail, and when it has, I forgot to keep the team focused. Any team can usually come up with a better solution than any single person can, you just have to figure out how to get them to collaborate. Forming a great question, one that defines the boundaries, usually gets unexpected, and outstanding, results.
Because they really mean the same thing. As a Product Owner we’re supposed to surprise our users when we can. When we cant surprise them, at least we shouldn’t bore them. When I’m getting feedback from the team or from the user community, if they’re about to say “it’s ok” then just say “it’s shit” and let’s make it better.
I was fortunate to listen first-hand to Steve Blank explain, in no uncertain terms, that if he ever found his Marketing team in the office again, he’d fire them. Because the answers aren’t in the office, they’re “out there”. So go “out there” and find the answers.
So many times I see people guessing at the answer as to why their product or feature isn’t being used. It’s ridiculous. Go talk to your user community, face-to-face. Watch how they use the product, watch if they use the product. If you’ve done any homework at all you’re usually just a few small tweaks from the feature being really useful. If you’ve just guessed at what feature your user community needs, well, then you’ve got a much bigger problem. You’re probably screwed to start with.
In one of the recent podcasts I listen to the statement was made “…people just don’t know how to think…” and I’ve been struggling with identifying this for a while. One company I worked for, you could just see the decline in YoY profitability, yet they were on-boarding people (because the solution didn’t scale but that’s another post) at a tremendous rate. I characterized them as having a triangle shaped hierarchy – a lot of people in management positions but relatively few doing actual work. At some point there would be just one poor schmuck at the bottom doing everything. You could see it, it was obvious, yet behaviors didn’t change. They literally looked like a bunch of 5 year old kids kicking the ball around on a soccer field. After unsuccessfully trying to point this out for a year, I decided to get the hell out. From the same podcast “..my dog is a genius [compared to these people], he knows what he needs and goes and gets it…” I’m baffled why people don’t understand what makes it profitable, and focus maniacally on those few things.
Here it is: provide clarity where there may not be any, and enable the team to consistently and predictably deliver value to the company.
Some may describe this as the intersection of UI/UX, Business, and Tech. Others may describe this as building the right feature at the right time. It is without a doubt, a strategic business role that requires both long and short term perspectives.
How do you measure the success of a Product Owner? As Josh Elman has stated, “The only metric that matters is, are people using your stuff?”
That’s it, keep it simple. If you can’t keep things simple, you can’t execute consistently.
One of the best lessons of product ownership I ever got was from a CEO who asked me “How did this get away from you?” My response was “Well, Marketing took it over…” He lost his shit over that response, and rightly so. The initial intent of the product got away from me and got watered down. What launched publicly was embarrassing and had almost nothing to do with the original intent that I had identified. When you bring people on to help with a product (and you’ll have to, you’re not omniscient) they should elevate the product. Add to it, improve it, make it better and make it something that everyone is proud of. If it goes to a committee, I guarantee you it’s going to turn into a piece of shit. You need one person that’s responsible for making sure it meets or exceeds the original vision of the product.
Building a solid product, or even building a solid product team, takes time. If you’re responsible for a product and you don’t understand this, it’s going to be a difficult time for both you and the team.
Here’s an analogy. Races aren’t won on race day. They’re won or lost on all the days leading up to it. Race day is where you show how hard you’ve worked on all the little, seemingly inconsequential tasks. I’ve seen some people show up on race day and think they can just push themselves harder than anybody else. But their lack of dedication and commitment shows quickly and they get left behind. You’ll usually hear these people say “we didn’t work hard enough in the race” completely missing the point that excellence is a day-to-day habit. It’s incremental. It’s trying to get .5% better every day, and even that is exceedingly difficult to do. A tiny improvement every day completely changes the end results you’re able to achieve, and, in my opinion, they stick with the team over time. It’s the same with a product and the team building it. Tiny changes make a big difference in the long run.
Tom Wujec. Singularity University, Sketchbook, Autodesk. If you have not yet seen his TED talk on visualizing complexity, you may want to see that first and come back. At the end of the video he describes how he help a company recover approximately $50 million in revenue. Most of it recovered when the company’s executives realized how overly complex their business processes were. Lots of waste. Lots of lost revenue.
They’re not unique. How well does your team understand the business processes which govern the day-to-day operations? When I hear managers say “I have to protect the team…” I absolutely know that there’s bureaucracy running unchecked. Have a handful of teams doing this and your company will begin to slow to a crawl and you won’t know how it happened. Well meaning people to be sure, but unaware of the implications of adding process on top of process. As a CEO or COO, make the investment in understanding how the teams and their processes affect one another. You’ll be shocked at how much this is slowing you down.
Overall investment in Florida increased 162% from Q2 to Q3 which was driven mainly by Healthcare Services and Biotech. Total investment in Q2 was about $57 million while Q3 was roughly $93 million, ranking Florida 13th overall for investment for the quarter.
Interestingly enough, both late stage and early stage investment expanded from Q3 to Q2.
I found myself trying to explain, in detail, how startups allocate shares and on what basis. My common answer is “who risks the most, gets the most” but below that, how do you technically set up allocation of shares? Since I’ve only done this on one of my startups, I’m clearly not a go-to person to answer any of this. There are several investors out there that strive to be as transparent as possible. @FredWilson, @jason, @davidcohen, and @bfeld being the top four resources in my opinion.
I was looking for guidance on how to authorize shares, and then the mechanism to issue a specified percentage of shares to the founders. I also wanted to better understand what the non-obvious effects are to the founders down the road when it comes to issuing or authorizing more shares, or an equity event occurs. What I found was this post from Fred Wilson (the link to answers.onstartups no longer works, here’s another link to the post by Joel Sposky that Fred refers to.)
If you need guidance on how to handle giving equity to advisers, Jason Calacanis has a pretty detailed rundown here.
If you do issue shares that have restrictions (such as a cliff, vesting, etc) you have 30 days to file your 83(b) election to the IRS. The topic is covered in Do More Faster by David Cohen and Brad Feld. There’s an in-depth discussion of it here.