I’m seeing this sentiment about Slack quite a bit these days:

Am I the only person who feels like Slack has turned into an even less controlled, one-more-thing-to-check, inbox?

— Craig Mod (@craigmod) June 2, 2015

I am now on nine Slacks and I get DMs in all of them and this is rapidly becoming untenable

— Erin Kissane (@kissane) June 2, 2015

This is such an interesting side effect of being successful. Slack is an amazing product, and the way they’re building it is nothing short of remarkable. From their launch strategy to the way they keep innovating, it’s a wonderful case study.

But now something else is happening. Slack is so successful that public groups have exploded, and it’s not uncommon for people to switch between 5 or more Slack accounts during any given day. I think we’re now learning that the thing that makes Slack so useful also requires it to remain a relatively small part of one’s workday.

Slack is a great communication tool, with integrations that make it possible to reduce the amount of time spent on other services. But once you have multiple accounts and multiple rooms to contend with every day, it has the potential to become worse than that technology we all love to hate—email. At least with email there’s an assumption of asynchronous communication. With Slack there’s always an expectation to get an answer immediately, so the stress it induces can really skyrocket out of control.

What a predicament. This is a product that is incredibly useful, but that needs a relative measure of quietness to remain so. This means that explosive growth actually hurts its utility. What an interesting design problem to solve…

Kate Heddleston makes some great points in The Null Process:

When people say they don’t want process, what they’re really saying is they don’t want formalized process. There is really no such thing as “no process.” A process is simply the steps it takes to complete a task, so if a task is completed then by definition a process was used. Without formalized process everyone does things their own way, and there is no documentation for how problems are solved. This informal, undocumented process is the “null process,” and, if used incorrectly, the null process can have major implications for a company.

This reminds me of two things. The first is Rebekah Cox’s definition of Product Design:

Design is a set of decisions about a product. It’s not an interface or an aesthetic, it’s not a brand or a color. Design is the actual decisions.

What this implies is that everything you do in product design has a consequence. So just “letting things happen” is also a decision. It’s just a pretty bad one. Maybe that should be called “null design.” I don’t know, I’m not good at naming things1.

The second is Michael Lopp’s The Process Myth. The whole thing is great, but this quote in particular has always stuck in my mind:

Engineers don’t hate process. They hate process that can’t defend itself.

Also this advice:

Healthy process is awesome if it not only documents what we care about, but is willing to defend itself. It is required to stand up to scrutiny and when a process fails to do so, it must change.

For more reading on what it takes to build good processes (because let’s be honest, what else are you going to do on a Friday night?), I recommend Adam Wuerl’s Avoiding Process Hell and Jeff Gothelf’s Applying Product Thinking to Process Improvement.

---

1. Just look at my URL. Seriously, what was I thinking. ↩

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.

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.

An interesting counter-argument to the #noestimates movement—and a call for reasonable software development estimates—on the Clever PM blog1. From In Defense of Estimates:

From a business perspective, some level of estimation is absolutely required, so that judgment calls can be made as to priorities of execution and communications within the company and to customers. We need to have some level of understanding of whether something is “bigger than an elephant or smaller than a breadbox” so that we can deploy other parts of the organization appropriately. “It takes as long as it takes” is not useful for tactical or strategic planning within any organization.

---

1. It’s kind of hard for me to link to this. First, there’s no byline, and I’d love to quote the author by name. Also, wow, that stock image… ↩

Some interesting perspectives from Dharmesh Shah in Why Your Startup Should Ignore Your Onboarding Experience (For Now):

Great user onboarding makes users say, “WOW, this is awesome,” and recognize that your product is a must have experience. But these WOW moments don’t come easy. And the mechanics by which you onboard users is just a small part of whether or not they fall in love with your product.

The more substantial part of the equation is the value your product delivers to your user: something in their life that must get easier, faster, cheaper, more productive, more fun, etc. because of using your product. Otherwise, why would they switch?

And that’s the difficult part to create. That’s the part that requires customer development and experimentation. It requires you to test your assumptions, to pivot, to try new things.

His recommendation is to do completely manual onboarding at first—contact every new user to find out why they starting using the product, email users who become inactive, etc. It might not scale, but it provides invaluable feedback at the inception of a product. Once you get to about 100 active users, Shah believes you know enough to create a great in-app onboarding experience. Food for thought!

Good thoughts from Martin Eriksson on how the PM is not The Boss. From Product Management is a Team Sport:

The bottom line is that everyone in the company owns the product, and its success or failure lie in the hands of everyone who touches it. A product manager’s job is to lead the team to tackle the product challenges together, to get the best out of everyone on the team when building the product, and to provide a gentle hand to keep it all consistent and going in the right direction.

Chris Baraniuk looks at the futility of things like traffic signal buttons in Press me! The buttons that lie to you:

Some would call this a “placebo button”—a button which, objectively speaking, provides no control over a system, but which to the user at least is psychologically fulfilling to push. It turns out that there are plentiful examples of buttons which do nothing and indeed other technologies which are purposefully designed to deceive us. But here’s the really surprising thing. Many increasingly argue that we actually benefit from the illusion that we are in control of something—even when, from the observer’s point of view, we’re not.

Back in 2012 I wrote the following about a blind spot I’ve noticed in Agile development:

Problem solving involves not just iteration, but also lots of variation. This often requires time to get it wrong a few times, which doesn’t fit comfortably with the concept of release dates. See, the problem with integrating Agile and UX is not that designers want to hang on to “slow and heavy documents,” “big upfront design”, or whatever you want to call it. The problem is that each iteration further solidifies the chosen path, and there is no time to stop and ask if you’re going in the right direction.

All of that came flooding back when I read Jeff Patton’s Common Agile Practice Isn’t for Startups, in which he puts a slightly different spin on the issue that Agile is not very good at helping us figure out what to build. His solution is a product discovery process (something that’s obviously near and dear to my heart as well). He places the discovery process in the context of a different kind of velocity than is usually measured in Agile—trying to learn as much as possible about customers and the product:

There’s something very different about this process loop: the primary measure of progress during discovery isn’t delivery velocity, it’s learning velocity. And sadly, we can’t measure it in features or stories completed. And, even worse, we can’t plan two weeks of it in detail because what we learn today can and should change what we do tomorrow.

He goes on to describe a Nordstrom process:

Notice the Nordstrom Lab still uses time-boxes, 1 week in this case. But, they didn’t start the time-box by predicting how much they’d deliver, but with learning goals in mind. Then they iterated around the build-measure-learn loop as fast as they could.

The post is hard to quote from, so really, just go ahead and read it. It’s a very interesting approach to making discovery part of a regular Agile process.

Marty Cagan continues his excellent product autonomy series by discussing what happens when teams get large enough to split up their code bases. In Autonomy vs. Ownership he describes his preferred way of dealing with the situation where a team needs a change in a different codebase to get one of their features implemented:

The alternative model is informally known as the “open source” model although to be clear this is not about open sourcing your code, it’s just called that because this is how much of the open source community operates. In this model, if the drivers team needs a change to the riders team’s code, then they could either wait for the riders team to do it, or they can actually make the change themselves, and then request that the riders team review the change, and include it if they’re okay with it (known as a “pull request”). This means that you are telling the software management system that you’ve made a change to the software, but the owner of that software needs to review the changes before they are actually approved and incorporated.