Shaun McCormick describes Why the way we look at technical debt is wrong:

Technical debt is ok, and often a solid product strategy. The importance is getting to market. When launching a new system or feature, focus your effort and time on areas of the product that need to be agile, and move quickly through areas that don’t. Later, if the product proves that it can drive revenue, you can revisit those areas and improve if they need to scale.

This is an excellent sentiment, and I agree 100% in theory. The problem is that in most organizations, “later” = “never.” Or as Jeff Gothelf puts it, the biggest lie in corporate america is Phase 2.

That’s why I really like Henrik Kniberg’s concept of a “technical debt ceiling.” Read his post Good and Bad Technical Debt (and how TDD helps) for the whole explanation, but here’s a diagram that explains his point:

Source: Henrik Kniberg

This forces teams to pay attention to technical debt, and make a conscious effort to reduce it when it becomes a problem.

“Mobile first” is more about progressive enhancement and making important design hierarchy decisions than it is about thinking about small screens, so I don’t agree with the “outdated” bit in Paul Adams’s Why ‘mobile first’ may already be outdated. That said, he makes a good point about enterprise software:

Many businesses being advised to go all in on mobile screens, should consider how often they are accessed while people are at work. Software that people probably shouldn’t, but do, look at on their work computer: news, sports, social, messaging, personal email. The large screen matters.

Now imagine that you actually build software specifically for people to use at work. This may be software for getting work done, such as Google Docs, Intercom, Slack, Basecamp, Trello, etc. The likelihood now is that the larger screen is the most important one. The large screen app is more important than the mobile app. The mobile app plays a different role to the large screen app, and in many cases a supporting role.

I see this is in our user research all the time. If we do usability testing on our mobile apps, one of the first questions is always, “Will I be able to use this on my desktop”? For software that gets used mostly at work, focusing on desktop — as unsexy as it might sound — is still hugely important.

Thomas Schranz writes in Product / Market Fit is a Trap:

Obsessing about product/market fit is a huge waste of your time. Yes … waste of your time. There … I said it again. […]

As I said above you don’t want to focus on product/market fit. You want to focus on building a great product and on getting it into the hands of your customers.

First, let’s talk about tone. I’m pretty averse to absolute language like “it’s a trap” and “it’s a waste of time.” Things are rarely that dramatic, but I guess nuance doesn’t play very well on the internet. This is also the problem I have with proclaiming that “flat design is evil.” A good designer won’t let an aesthetic trend get in the way of affordance and visual hierarchy. A good designer will work within the constraints of a particular aesthetic to accomplish their (and their users’) goals.

But I digress. On to the substance of the post…

If you read Marc Andreeessen’s entire post on Product/Market fit, you’ll see that Thomas and Marc’s views are not in conflict at all. Marc might use slightly different language, but his definitions of product and market are very similar to what Thomas proposes above (my emphasis added):

The quality of a startup’s product can be defined as how impressive the product is to one customer or user who actually uses it: How easy is the product to use? How feature rich is it? How fast is it? How extensible is it? How polished is it? How many (or rather, how few) bugs does it have?

The size of a startup’s market is the the number, and growth rate, of those customers or users for that product.

Marc is using VC terms, but his meaning is clear: build a great product, try to get more people to use it (or as Thomas puts it elsewhere in his post: focus on product and distribution). It is up to us as product designers and product managers to figure out how to make that happen. Jobs to be Done, Personas etc. are fantastic ways to do that. But those methods are not opposing theories of startup success, as Thomas suggests. They’re a continuation (the how) of Marc’s Product/Market fit framework.

Christina Wodtke writes about the intersection of design and business in Why Design Needs Entrepreneurship (and Entrepreneurship Needs Design). This is a particularly nice summary of the three major startup handbooks in high circulation these days:

Steve Blank said you should talk to your customers as you develop your offering. He said there were no answers in the building, you must go out into the world if you want to make something people want.

Eric Reis said you should build small things, test them, learn, then build the next thing until you find successes.

Alex Osterwalder said you should look at all aspects of the business and design them collectively to assure a successful ecosystem. While all three hold a distinctly user-centered design approach, Osterwalder is the first to state it unambiguously, using design tools and innovation games throughout his book and calling them that. It is a designed book, in every sense of the world, and it was written in collaboration with a group of beta readers.

All three, at their hearts, are user-centered designers. They just happen to design business.

This is a great call for designers to care more about the business of design.

Benedict Evans wrote a characteristically brilliant analysis in What does Google need on mobile? Here’s a taste of his conclusion about Google’s challenge going forward:

The key change in all of this, I think, is that Google has gone from a world of almost perfect clarity—a text search box, a web-link index, a middle-class family’s home—to one of perfect complexity—every possible kind of user, device, access and data type. It’s gone from a firehose to a rain storm. But on the other hand, no-one knows water like Google. No-one else has the same lead in building understanding of how to deal with this. Hence, I think, one should think of every app, service, drive and platform from Google not so much as channels that might conflict but as varying end-points to a unified underlying strategy, which one might characterize as ‘know a lot about how to know a lot’.

Don’t miss this article, the whole thing is great.

Alina Senderzon defends realignment strategies in Resist the Redesign:

Yet, designers are quick to jump on redesign opportunities—after all, it’s exciting to start anew. In reality, however, a redesign isn’t always the right solution to the problem. The roadblock for users may lie in the pricing of your product, which could be discovered through customer development. Or your messaging isn’t compelling and could be saved by some clever copywriting. Or maybe customers feel compelled to convert, but the checkout process is too long and needs to be streamlined. Any number of changes could generate dramatic value for the business, and though they likely involve some design decisions, they rarely require a clean slate.

This is similar to the approach I wrote about a couple years ago in The Data-Pixel Approach To Improving User Experience.

If I link to a listicle, it has to be good enough to overcome my unnaturally strong negative feelings about those types of article. Alas, Mike Fishbein’s 4 steps to make experimentation a repeatable process in your business is that good. It’s a great overview of the importance of hypothesis testing over “requirements gathering” in product management:

Most new products fail, and most frequently because they do not meet user needs. Running experiments helps product managers validate customer demand for a product concept earlier in the product lifecycle.

By running experiments instead of launching a minimum viable product, product managers in large organizations can gain more autonomy, limit risk and brand exposure, and gain user insights even earlier in the product lifecycle. With this speed to user insight, product managers become better informed to build successful products.

I also especially liked this bit:

In the next evolution of product management, the product leader’s role shifts from making bold assumptions to fostering a culture that encourages learning in an efficient and effective way.

Scott Sehlhorst wrote a really good defense of good product roadmaps in Features do not a Product Roadmap Make:

If your roadmap says “Will include update quantity control in shopping cart” you’re doing it wrong.  Your roadmap should say “Improved shopping experience on mobile” or “Better shopping experience for spearfisher  persona.” […]

When a roadmap is being used to communicate “what” the product will be, it should be in the language of describing which problems will be addressed, for whom, or in what context.  This is the most important type of theme which would be part of a thematic roadmap.  Other themes could be “improve our positioning relative to competitor X” or “fill in a missing component in our portfolio strategy.”

And this, in the context of agile, is a great point as well:

A backlog – a prioritized list of features – is not a roadmap. It is a reflection of a set of design choices which happen to fulfill in product what the roadmap sets out as a manifestation of strategy.

A roadmap tells you both “why” and “what;” a backlog tells you only “what.”

This reminds me of an article I wrote in 2011 called Product roadmaps are safe. Good times.

Dave Pell—in the context of Facebook’s plan to host news sites’ content natively—explains what tech people are good at (and usually not good at) in Don’t Take a Flying Leap:

But building a really successful app or site does not mean you know more about education than educators. Disrupting the photo-sharing space does not qualify you to disrupt higher education. Or to understand the health system better than doctors. Or to understand the woes of urban poverty better than those who have spent a career on those corners. […]

This is not the time to give up and it’s not the time to give in to one of the most prevalent myths of the era: that people who can build technology know how to run your business better than you do.

Douglas McGray’s How Carrots Became The New Junk Food is not about carrots. I mean it is, a little bit. But it’s mostly about product positioning and marketing.

“Everyone else pitched baby carrots as an antidote to junk food,” [Jeff] Dunn says. “Where [ad agency Crispin Porter + Bogusky] came out was almost the exact opposite. We want to be junk food.”

They realized that junk food is desirable. So instead of pitting carrots against that industry, they decided to play to its strengths instead. And it worked:

Crispin imagined individual snack packs made of opaque, crinkly plastic, like a potato-chip bag, with bold, junk-food-style graphics (the new packaging would cost about 25% more than traditional veggie bags, but Dunn could justify it as a marketing expense). “People are now grabbing a bag of these, you know, eating them in the car,” Dunn’s marketing chief, Bryan Reese, says. They’d look right at home by a convenience-store checkout.