David Cancel has some interesting thoughts on how they split up product management and tech team responsibilities in How we transformed HubSpot into a Product Driven Company. I really liked this part about embedded designers:

While we kept the core technical team tight, they were bolstered by the presence of embedded product marketers and UX designers all fixed on the same problem and solution. Designers and UX researchers informed the product teams from the point of mockups, through testing phases, to the ultimate release and support the product. […] The upshot here is that product teams become wholly self-sufficient organisms. They are small enough to retain customer focus but still have the skilled resources they needed to design, test and market the solutions they developed.

That post led me to Jeremy Crane’s What does a Product Manager do at HubSpot, which goes into more detail on the PM/Tech team split:

Every product team’s job is, essentially, to solve problems for their customers. Solving problems involves two key components: (1) Understanding the problem, and (2) creating the solution. At HubSpot the product manager owns the “problem” and the technical team owns the “solution.”  The “problem” is defined by whatever is likely to produce the greatest value to the customer and the business at large within the area of influence. The “problem” is both long-term and short-term in scope. It addresses the immediate challenges that the customer is experiencing, while still keeping an eye the longer-term vision of the product as a whole.

Scott Sehlhorst makes some very good points about different levels of roadmap detail in Opposite Views of a Product Roadmap:

Depending on your role in your organization you will be biased towards viewing your roadmap either as a view of what the team will be building into your product, or a view of why the team will be building things into your product.  As a product manager, it is imperative that you can view it both ways.

When it comes to what you’re building, the roadmap gets less precise as you move further out:

I describe rolling-wave planning as being precise about the immediate-term future, having less specificity about the near future, and being nonspecific (but still helpful) about the more distant future. This is because – from the perspective of someone focusing on what they will be doing – there is too much uncertainty about what will happen between now and the future. (BTW, this is where waterfall is wasteful – it assumes incorrectly an ability to predict the future in detail.)

In contrast, when it comes to why you are building what you’re building, it starts off fairly broad and becomes more precise as you go on:

In the “right now” the team is testing hypotheses. Given a customer, and a problem the customer is trying to solve, there is a hypothesis about how best to help. That hypothesis is a design. The design may or may not be a good one. The implementation of the design may be great, adequate, failing, or incomplete. In this time horizon, the activities of the team building the product are concrete – build, test, learn.

The way I would summarize Scott’s post is as follows. When it comes to product planning, be rock solid on what problems you’re solving for which customers, but be open to data-informed change when it comes to short-term implementation details.

I really liked this interview with Josh Porter where he talks mainly about good product design, and the importance of user feedback:

Good product design is the result of persistence as much as anything else. That’s why you hear companies like Airbnb and Evernote and others say that it can take years to figure out user onboarding or free trials or other sophisticated flows. It takes a lot of time to get your message right, get the user incentives right, get the interaction right, etc. It is easy to become impatient and throw out some great ideas prematurely.

And this:

The interplay between vision/intuition and data/feedback is that you need both. You need to be able to assess how you’re currently doing with data but also not let data stop you from taking risks with your product. Many teams become conservative over time as they rely more and more on data to make decisions. They ultimately become paralyzed and unable to build something really new.

Apps that provide daily news summaries are the current rage. It appears that we’ve moved on from our Weather app and Messaging app obsessions. It’s a worthy goal, though. We’ve created so much noise on the Internet, we owe it to people to build tools to help them navigate all the noise we made. It’s the only viable solution.

Cynicism aside, though, I download all these apps and try them out. Sometimes they rotate on to my home screen for a while. Yahoo News Digest lasted a while. Everyone loves Circa so I tried that for a while, but it was still too much for me. The problem with the news is that it never ends — there are no edges — which is the reason these apps exist in the first place.

The one that I keep coming back to is NYT Now. I really, really love this app. The morning and afternoon briefings are succinct, and give me the sense that I got the day’s most important news. And I can dig deeper if I want to. It’s on my home screen and will probably stay there.

The latest entry to this market is Flipboard’s The Daily Edition. I use Flipboard every day (hey, you should subscribe to my Flipboard Magazine!), so it’s a natural extension and one less app to follow. My only problem with it so far is that I can’t remove sections I’m not interested in (Sports, ugh).

Anyway, the reason I write about this is that there’s something I don’t understand about this space. All these apps were built from the ground up to do some kind of human curation and give people a sense of the most important news of the day. But the two companies that have all the data in the world to make this happen — Facebook and Twitter — haven’t jumped in. I guess you could argue that Paper is Facebook’s attempt at this, but not really because they hedged their bets by making it a full-featured Facebook client anyway.

I don’t know if this is Innovator’s Dilllemma or what, but it seems like these two companies could make kick-ass daily news apps with data they already have at their disposal. Why haven’t they done this?

Marysol Elorriaga discusses the challenges of implementing Lean methodologies in large companies in Getting buy-in while moving at rocket speed. One of the guiding principles is to “Release early and show results”:

To make the stakeholders feel like they are getting something equally valuable out of taking the “Lean approach”, deliver the MVP early and show results. Ensure that all features to be released can be measured and there is a proper feedback gathering mechanism in place. Ease the concerns of working under the Lean philosophy with weekly dashboards, including customer feedback, learnings from user validation/testing and analytics. Ultimately, having big data and skilled professionals to transform customer feedback and analytics into business insights is a pre-requisite for improvement and innovation.

From the same blog, Elizabeth White gives some advice on embedding a Lean team in a large company in Building the Right Culture in a Lab Environment. It’s especially important to understand that “We are Lean Enterprise – not Lean Start-up”:

Our room is lean but we are surrounded by a waterfall. While we are fully supported by TELUS, and most internal teams want to roll out what we are doing, we are a big company, depending on some serious backend systems. And while I can go on about our fantastic experience and the merits of working in a lean environment, it is important to note, waterfall shouldn’t become taboo either. There will be projects where waterfall methodology makes perfect sense, there are some – much like ours, where a hybrid approach is best and there will be some, where lean, in its purest form, is the correct path.

If you’re thinking of trying a Lean approach in a large company, there’s some great advice in these two articles.

Marty Cagan wrote one of his characteristically great posts in Product vs. IT Mindset. In one particularly harsh section he describes what happens when the people who make decisions about a product are far removed from those who make the product:

In IT mindset companies, accountability frankly is a farce. The people actually working on a project typically have no real say in what they are building, and sometimes even in how it’s built, and even when it’s due. In theory, the leadership team could try to hold the requesting stakeholders accountable for the results, but if they do they immediately hear complaints that they didn’t get what they actually wanted, and because of delays and costs, critical things had to get cut, and so it’s certainly not their fault. So management writes it off as yet another failed technology initiative. In contrast, in a product organization, we are measured by results.

I’ve always felt that this is the biggest challenge to companies as they grow. The further away those who make decisions are from those who build the product, the harder it is to remain customer-focused in the long term.

As I’m sure you’re extremely tired of hearing by now, I recently wrote a book on Product Management. For those of you who are too cheap to buy it (I kid, I kid1), there is now an edited chapter excerpt up on Smashing Magazine. In Why Companies Need Full-Time Product Managers (And What They Do All Day) I give my definition of Product Management, and go into some of the characteristics of a good PM. Also:

The truth is that, to be effective, the role of a manager for a particular product or area must not be filled by multiple people. It is essential for the product manager to see the whole picture — the strategic vision as well as the details of implementation — in order to make good decisions about the product. If knowledge of different parts of the process resides in the heads of different people, then no one will have that holistic view, and all value will be drained of the role.

Enjoy the freebie!

---

1. But not really. PLEASE BUY IT. ↩

I was a little reluctant to click on Greg Satell’s How Wells Fargo Learned To Innovate Around the Customer. First, it’s on Forbes, which has become virtually impossible to read on mobile devices because there’s so much blegh on the page that’s not related to the article. Second, whenever you see people talking about “The Customer”, you should be sceptical. There is no average “user” or “customer”, so this kind of thinking usually results in defining an impossibe target market:

Image source: Tom Fishburne.

That said, despite my fears, the article is quite good. It discusses how Wells Fargo uses ethnography in their business, and there are also signs that they don’t operate like a large, slow-moving corporation at all:

However, it is not just internal processes that have changed, but the culture as well. Ellis’s bankers don’t sit in cozy offices, quietly examining financial statements (nor does Ellis himself), but work in open cubicles designed to promote collaboration. They are constantly iterating, experimenting and testing.

This part, especially, surprised me:

Perhaps most importantly, they are not limited by a long range plan. There is no “five year death march” toward a transformation that will never happen—or be outdated by the time it does. Instead, their purpose is to improve their customers’ businesses and adapt quickly to shifts in technology and the marketplace.

I’d love to see more detail on how Wells Fargo remains lean despite being such a large company. If this is really how they operate, it’s encouraging proof that big doesn’t have to equal slow and tired.

Some smart thoughts from Scott Sehlhorst in Classifying Market Problems:

Many teams struggle with backlogs or roadmaps which appear to be a collection of “a bunch of stuff.” Most teams try and address the problems that manifest from having a giant list of stuff by getting better at managing giant lists. This is treating the symptom, not the cause. If you’re trying to juggle hundreds of requirements, the problem isn’t that you have hundreds of requirements, the problem is that you don’t know why you have requirements.

Which reminds me of this cartoon, because that’s what happens when you get better at managing lists instead of getting better at figuring out how to make your product useful:

Of course, it’s also at this point that users tend to take matters into their own hands:

I don’t know if I’ve always wanted to write a book, but I do know that I’ve been writing the one I’m announcing today in my head for many, many years. It’s called Making It Right: Product Management For A Startup World, and it’s my attempt at putting together a practical framework for building great products:

The book came about because I saw a lot of people in organizations perform some of the activities that make up the role of product management. The problem is that very few people take a holistic view of the product, and this is not a role that should be split up into tiny pieces. So, you see marketing people doing some design and research, business analysts doing some spec writing, developers managing the product backlog, and so on.

All this without a person who is responsible for the overall vision, prioritization, and execution of the product. With this book I wanted to provide a complete product strategy that is agnostic to whatever development process people use (agile, etc.).

So here are a couple of links to check out more detail, if you’re interested:

• Smashing Magazine has a launch post up today.
• You can buy it directly from Smashing for $10 in their digital store.
• For the next couple of days, you’ll also be able to buy it for 99c on Amazon.

Smashing tells me that the Amazon thing, in particular, is important for the first couple of days after launch. So if you’re so inclined, please pick it up for 99c, and write a review. It will really, really help to give us a good launch.

Huge thanks to the Smashing Magazine team, and my technical editor Francisco Inchauste. They’re my heroes. And now I have to lie down.