The World Health Organization estimates that 15% of the world population is disabled. After the initial shock about that statistic sets in (that is a lot more than I expected), you may ask why I’m writing about it.
People with disabilities are on the web every day, trying to use your product, just like their non-disabled peers. However, I’m willing to bet that accessibility is an afterthought as you design and build. That does not make you a bad person. Far from it. It just makes you unaware. Unaware that you are ignoring a significant number of users who may find your site, who may want to signup for your site or even pay you money. Your particular user base may over or under index, but even if a conservative estimate is just 5%, you should address this issue. Imagine if your dev team told you they would no longer support a browser that accounted for 5-10% of your traffic? Seems crazy, I know. That is effectively what you are doing when you ignore accessibility on your site. Continue reading “Accessibility”→
I hate weasel words. So many words get bastardized and misrepresented, especially in business, but it happens in politics, science, and other fields too. They become trendy. They become buzzwords. Companies feel they need to use these words or else they look like dummies. Guess what, most of the time when you use the terms incorrectly, you look like a complete dumbass.
Some of my favorites from the software / startup world…
“Platform” – your website is not a platform. It’s a website. Or maybe it’s an app. Unless other people can independently build whatever they want on top of your software, you are NOT a platform. Stop it.
“Disruptive” – everyone thinks they are disrupting things nowadays. Really? Giving people a new filter to put over their picture of dinner is not fucking disruptive. Poor Clay Christensen. I’m sure he had the best of intentions, but the jackals hijacked his concept. Now it’s meaningless.
The one I’m going to deep dive on today is “MVP.”
Thanks to Eric Ries and Steve Blank, everyone’s talking about MVP nowadays. However, in my observations, people are using it as an excuse to put crappy shit out there. MVP doesn’t mean it’s OK to be crappy. Your product still needs to be good. Most of all, it still needs to be valuable and meet whatever goal your user is trying to achieve. Otherwise, all you have done is spent money to “test” and make someone’s day worse. They’ll never get that time back from trying your sloppy product. Don’t do that to them. There is enough anguish in the world.
A better term would have been Minimal VALUABLE Product. I think that re-frames the context in the right way. What is the simplest, most straightforward way to create value for your user? Reframing the question in that way puts it all in perspective.
The team at Spotify has nailed this. Below is from a presentation given by XX that illustrates what an MVP really is.
Image credit: blog.crisp.se
It’s simple, but powerful. If your user’s goal is to go somewhere more quickly, you should maniacally focus on that. Even if you are the next Steve Jobs and can dream up the most badass sports car to serve that need, you have to start somewhere. You’re a lunatic if you think it’s best to spend 5 years building the dream of that sports car. Then you’re in waterfall hell with no shot at actually delivering the car on time, let alone managing the risk that what you dreamt up might not be what your user in 5 years may want.
Instead focus on the goal. Get somewhere more quickly. How would you do that. You wouldn’t start by giving them a tire. They can’t do anything with a tire, even if it might be a part of the end product. Reframing leads you to think about the most straightforward way to get your user somewhere more quickly. So you build them a simple skateboard.
BOOM. You deliver value immediately and your user is delighted. They can get somewhere faster. Then you talk to the user and ask him what’s challenging him now. Oh, you hare a hard time balancing? Why don’t we add a little steering column. More value. Build, Test, Gather Feedback, Hypothesize, Repeat.
In five years you end up with a sports car. But now you have a user who is a huge advocate because they’ve been benefitting from your awesomeness for five whole years. Isn’t that awesome? I think so.
So, take off your black turtleneck and stop building sports cars. Reframe your problem around your user’s goals. Then think really hard about how you can meet that goal in the simplest, most straightforward way.
Other great articles on this topic can be found here, here and here
The “Line of Chaos” is a concept that good product managers will not just understand, but will embrace with vigor.
First, let’s start with what it is. It is an imaginary line that serves to illustrate the interface between business and technology. Why does that interface matter? It matters because business people and engineers are fundamentally different.
Recall the post by Paul Graham about Makers vs. Managers. Business people, especially sales people, thrive on selling, meetings, making clients happy, reacting to the client or market, the (not so) occasional fire-drill, and often just raw activity. They are interrupt-driven. How many times have you heard someone say, “I’m so busy! Look at all the meetings I have on my calendar.” They frequently switch context. They lie in the now. It is often fluid, reactive, and, well, chaotic.
Engineers (I’d include designers in this too) thrive on long blocks of deep thinking to solve problems. Output should be the measure of productivity for engineers, not the activity or the lines of code. In fact, time to think, not code, may result in the best output (a scalable design or elegant feature, for instance).
None of this is controversial. The thing that isn’t mentioned in the PG article is how those two different worlds can work together to great effect. This is where product managers step in. They are responsible for defending the engineers from the chaos. In some ways, they are responsible for saving the business people from their own chaos (even if they might not know it at the time). PMs are the keepers of the Line. Good PMs will fight to the death to ensure that the Line does not penetrate the engineering team.
The keeping of the Line of Chaos takes many forms for a PM. Prioritization. Stakeholder management. Feature benefit analysis. MVPs. Product strategy. At the end of the day, these and other common principles of product management are just tools to fight back the Line of Chaos.
This is not to say that the Chaos does not serve a purpose. It does. Great ideas often emerge from the chaos. But, even then, the idea is going to need some help to get presented to the engineers in a way that puts them in a position to be successful.
Great product managers are hard to find. There aren’t a lot of people who can both operate in the chaos, while simultaneously fighting it.
We are now about five months into our transition to Scrum. Embarking on the experience as a Product Owner has been awesome. I recently came across a useful graphic that outlines the skills (and there are many) that make a good product owner.
This is a good summary. I would add Authority to the chart (but that messes up the layout of the poster, so I’m sure the creator had to make some hard decisions). Authority is a more nuanced form of leadership, in my opinion, but it is important to call it out on its own. Authority comes from your domain expertise, and the way you carry yourself with the dev team and the rest of the organization. You earn this, you don’t just ‘have it.’ It’s a hard thing to master, but it is instrumental to your success as a PO.
Uber is a new-ish app that has consumers falling in love with it and regulators hating it to the core. As a basic primer, Uber is a mobile app that allows a consumer to hail a hired car (towncar, SUV, or taxi) on-demand in a matter of minutes. Not only that, but it allows the consumer to track the car as it approaches, with estimates of how long it will take to arrive. Then, once a consumer is in the car, all payments are handled automatically, with an email receipt sent immediately after the trip is completed. No hassle with credit cards or digging in your pockets with cash.
When I first heard about Uber, I’ll admit that I was quite skeptical about the whole concept. After all, what was so difficult about calling the cab company and asking them for a cab, waiting for the cab and then paying like you always did once you were in the car. I’m skeptical about the “convenience” of mobile payments when the consumer has to pull something out of their pocket and process a payment; whether that is a credit card or a mobile phone, there’s really no difference.
However, since my initial skepticism, I’ve become a believer. Some of it probably has to do with my first experience with the app. My girlfriend and I were stranded in San Francisco after a wedding reception, fighting for a cab on the street corner with a bunch of other bar-goers and watching cab after cab pass us by. I remembered that this new service was available in San Francisco, so I whipped out my phone, downloaded the app, signed up and within literally two minutes, a nice black sedan pulled up, the driver got out and greeted me by name. We were back at our hotel within 10 minutes and we even to a nice bottle of water to enjoy on the ride home.
newmanea 