It’s a bit sad to see this end. I haven’t installed SETI for some time, but back in the day, I had it running as a screensaver on my old Gateway tower. It ran for 20 years, which is quite an achievement.
In this weeks episode of the Rework podcast, DHH discusses how difficult it was to cancel his SiriusXM radio subscription. They deep dive into newspapers as an example of this problem (which crosses industries in my experience, Cable TV comes to mind).
Newspapers make it easy to start a subscription but challenging to cancel. As is clearly outlined in this episode, the difficulty is artificial; there is no reason the newspapers have to make it difficult to cancel, they choose to do so as a tactic to retain subscribers. Papers are in a pickle because of their actions. True, the landscape has changed, technology disrupted the market, but ultimately it’s the newspaper’s actions that have caused their problem.
I’m a good example. I don’t subscribe to any newspaper. I do however spend $10 per month for Stratechery.com. I do pay around $200 per month on books. I’ve been through situations where I saw first hand the poor quality and biased reporting of journalists enough to know to be suspect of anything written by them. So I look elsewhere for my information. That is their fault.
If you are in a business that relies on these dishonest tactics to hold customers hostage you should think long and hard about what, if any, value your company provides. If your business is dominated by marketing, sales or finance and doesn’t have a reasonable balance of power to ensure the customer’s needs have priority then rethink your structure and organizational design.
No business has a right to exists. No company has a right to be dishonest in its marketing or advertising. No business has a right to customers.
Fortunately, it’s not a complicated recipe to be customer first.
- Talk to your customers. Understand the friction or frustration you introduce into their lives and eliminate it ruthlessly
- Observe your customers. Look for things they’ve worked around that you can improve and improve those things mercilessly.
- Ensure that the builders in your organization have a direct line to customers. Don’t have a bunch of intermediaries. Eliminate anything that puts distance between those who build the experience and the customer. If anyone in your organization says the builders (be they programmers, designers or engineers) can’t deal with customers, question if that person should be in your organization.
- Use your product as a customer. Don’t have “VIP” service offering for internal executives. If you are a leader, then use your product just as a customer would. If your customers suffer, you should suffer.
Tyler Cowen points the way toward sanity in this article in Bloomberg. It’s all too often we catastrophize things creating a scenario that oddly calls for no action on the very thing we’re railing against. It’s good to hear, every once in a while, a sober voice calling us to look at the real data.
I’ll occasionally listen to Vasco Duarte’s podcast, Scrum Master Toolbox. The most recent episode had Bas Vodde, co-founder fo the Large Scale Scrum framework (organizational design!). It’s a great introduction to the opinions and assumptions that underly any large organizational transformation attempt. Listen to the podcast online, well worth the time.
Creative Selection is a recently published book by one of the developers involved in the original iPhone program offers good insight into how Apple was able to bring to market a game-changing device. This is all from the vantage point of one the developers, not an executive. This view offers some unique insight into how a large scale product development effort can work – and in this case, work exceptionally successfully. I was particularly interested in the ways the process at Apple mirrored some of the best research-backed advice about how to manage product development. Going thru a large scale Agile transformation now, I found the parallels to advice in frameworks such as LeSS comforting.
“Every day at Apple was like going to school, a design-focused, high-tech, product-creation university, an immersion program where the next exam was always around the corner.”
A commitment to learning is so rare in most companies in my experience; the idea that a developer takes on a role that he has no knowledge of and “figures it out” with the help of other talented folks. The company trusts him to learn and adapt – and with an iterative process, this allows for check-ins to course correct. The developer must also be open to suggestions – even with deep feelings about the work done. The point is the product – move the product forward.
This is so obvious on one level and yet so incredibly difficult to implement in practice. The work of leading a group of people in this fashion is much more difficult than the standard big business management approach of making up deadlines and metrics and acting as if the management is separate from the process. Leaders are great at fooling themselves that it’s their genius that got them to the position they hold – one has to continually be on guard for this internal monologue and beat it back. Sadly, few leaders seem to be on active guard against this.
“The culture we created is inseparable from the products we created. In my experience, this manner of culture formation works best when the groups and teams remain small when the interpersonal interactions are habitual and rich rather than occasional and fleeting. The teams for the projects I’ve described in this book were small indeed. Ten people edited code on the Safari project before we made the initial beta announcement of the software, and twenty-five people are listed as inventors on the ‘949 patent for the iPhone.”
The default direction in most large enterprises is to either increase team size to add every little specialist’s role or split up work into smaller and smaller specialties (or both). The more I’m exposed to the issues of dealing with large teams and specialists groups the more the advice to target small teams of cross-functional people makes so much sense. In short, always move to simplify the organization. Added complexity will trick you into thinking you’ve solved a problem when in reality you are setting the stage for additional problems. Apple understood this, tellingly even in a project like the iPhone where it would have been the default step to create very large specialists teams.
“There are innumerable ways creative selection can become bogged
down,since this working method must be applied consistently over some time to yield results. Consequently, our success was as much about what we didn’t do as what we did. Mostly we avoided falling into any of the typical product development traps common in Silicon Valley and that, I expect, occur often other kinds of creative organizations and businesses. “
Among the things that they didn’t do are long discussions about products devoid of concrete examples that force a grounding in reality. They avoided using artifacts that were separate from the actual work – things like requirements or paper mockups.
Perhaps most importantly they didn’t have senior managers involved in decisions which weren’t personally engaged in the work. This is the root problem of management in some ways. The idea that they can be disconnected from he work and yet dictate, in the most disruptive way possible how the work is done. Continuously changing direction and causing confusions – but never changing the made-up deadlines they believe will push people to perform. It’s so perverse you’d think it was designed on purpose to hinder performance.
They didn’t set-up special research departments separate from the teams doing the work. Most companies have such little faith in their front line technical people. For some reason, there is this belief in hiring “special people” to do the interesting work. Think for a second about this. The same people who best understand how your systems work, best understand your customers are getting the shaft because you’re saying that they are incompetent to do the interesting work building the future. Set aside the fact that often when a company creates these special groups, they’re staffed with people who are better at selling themselves than doing work.
“At Apple, we built out work on this basic fact. Demos made us react, and the reactions were essential. Direct feedback on one demo provided the impetus to transform it into the next. Demos were the catalyst for creative decisions.”
Similar to a Sprint Review in Scrum – an opportunity for the team to show the work and gather valuable feedback that will inform the priority of the Product Owner and also what the team focuses on in future sprints. No matter the organizational model, a company, uses, this quick feedback is so critical and yet so rare.
“Scott took the chair at the long wooden table in Between, a Wallaby prototype tethered to a Mac lying on the desk. Scott picked up the Wallaby, and as he started each demo on offer in the switcher app, the programmer who created the demo stepped forward to describe how it functioned. These how-to instructions could be complicated. Some involved blue-sky interaction models, like one collogues’s complex multiple-tap scheme built around a few super-big Kays he could type on without looking. Others called for various orchestrations of multitouch input s to type letters, enter punctuation, and capitalize words. Scot was game to try everyone, and as always, he was upbeat and encouraging. He found something positive to say about each demo — good graphics, clever idea, interesting concept — but he was still having a difficult time. None of the keyboards offered quick and accurate typing.”
Perhaps the most exciting point in the book for me is here you have a prototypical technology leader – not someone who’s apt to be a pushover, and yet in this context, he was sure not to crush the morale of the developers. Even in the case of a keyboard, a do or die aspect of the phone, he was still careful to provide praise where he could and not fly off the handle that the team hadn’t solved this critical problem.
Creative Selection is an engaging, quick read. Highly recommended for anyone who’s interested in how the most successful consumer product in decades came to be. There are great lessons here for anyone dealing in a complex environment. Apple wasn’t perfect in any sense, but it sure does seem like they got some things right about complex development. Things that many if not most companies get entirely wrong.