There comes a point when you have to stop. We’ve all been there before. Sometimes it means your product strategy is saying “no”.

via Intercom

Obviously, saying “no” can’t be your only strategy. There’s a balance to maintain between adding new features, culling old ones and explaining how they all fit together.

To get you kick-started, we’ve collected four techniques to help you reduce feature bloat in your product:

1. Conduct a “Feature Audit”
2. Ask the question: “Does the feature fulfill a customer goal?”
3. Align features to your company’s vision
4. Are you making decisions that benefit a ‘loud few’ or the ‘majority’?

1. Conduct a “Feature Audit“

First, you can increase adoption and/or frequency of use of features with low adoption / usage frequency.

Be cautious if you’re trying to optimize these levers for every feature. Not all infrequently used / low adoption features are low value and can be perfectly fine as-is.

For example, an ‘updating account information’ feature — it’s infrequently used by all, but still necessary.

2. Ask the question: “Does the feature fulfill a customer goal?”

Arguably, the most important part in reducing feature bloat.

If you define the wrong goal, even a great team will develop a slick, fast and ‘cool’ feature which no one uses and/or wants.

How do you avoid it? Look into the motivations, situations and context of your customers. Not just the solutions. They come after. Job stories help with defining these.

• Job stories are like the context behind personas. While a persona might describe a person (which helps to form context), a person’s situation and motivation(s) when they’re engaging with your product could be completely different to their description of themselves or how they usually act.
• For example, someone who is usually a healthy eater (persona) might be tempted to eat unhealthy fast food because they don’t have much time to spare and need food that is energy dense (situation + motivation).

“People don’t want to buy a quarter-inch drill. They want a quarter-inch hole.” — Theodore Levitt

3. Align features to your company’s vision

Let’s look at Twitter’s vision:

“Twitter is your window to the world. Get real-time updates about what matters to you.”

One glimpse at this and it becomes obvious why Twitter haven’t lifted their 140-character tweet limit (yet). It’s not because they can’t. It’s because if they did, people would communicate in way that isn’t in “real-time” on Twitter. You can’t type essays on the fly about world events (and if you wanted to, there’s other platforms for longer-form writing, e.g. Medium).

Make sure to stick to your product’s vision or it won’t be clear who your product is for.

4. Are you making decisions that benefit a ‘loud few’ or ‘the majority’?

It’s not your job to make everyone happy. Of course, sometimes it will make sense to, but it needs to be blindingly obvious.

To get your ‘objective’ mind on track, you should be answering no to these kinds of questions:

1. Would you make your product free if 10 customers loudly complained that “it costs too much”, in contrast to 1000s of happy, paying customers?
2. Would you develop a feature because 10 non-loudly complaining customers asked for it?

If you have any other techniques to prevent feature bloat, we’d love to hear about them in the comments below!

The post Feature Bloat – The Silent Epidemic appeared first on Blossom.

“Good companies manage Engineering. Great companies manage Product.” — Thomas Schranz

What is product management?

Simply put, product management is the heart of a product team and enables you to:

“Help your team (and company) ship the right product for your users” — Josh Elman

As a product manager, you sit at the “intersection of technology, business, and design”, as Gayle McDowell puts it .

Solve your customers’ problems

But, product management involves more than just the product manager. It involves the entire team. Ultimately, the goal of product management is to help customers solve their jobs to be done with the software you deliver them.

That is, you help customers solve their problems.

Use the following influential product quotes to inspire your team to build products that make a dent in the universe.

Tweet this

Tweet this

Tweet this

Tweet this

Tweet this

Tweet this

Tweet this

Tweet this

Tweet this

Tweet this

Tweet this

Tweet this

Tweet this

Tweet this

Tweet this

Tweet this

Tweet this

Let us know if you know of any other inspiring product management quotes – we would love to expand the collection!

The post How To Build Products Like A Product Manager appeared first on Blossom.

I was fortunate enough to see Bill Scott of PayPal speaking at Silicon Valley Code Camp. He shared a number of amazing lessons learned on how to create great products. Here are six anti-patterns that Bill suggests your product team should avoid to move fast and keep shipping effectively.

Being perfect

There’s nothing wrong with ironing out all of the errors and UI kinks in a project— in other words doing something until it’s perfect. But, while bringing something to perfection, it’s absolutely critical that you try to keep an eye on continuously delivering your changes.

You don’t have to ship a completely perfect feature at a time — what for?

Just imagine yourself building something until it’s perfect. You spend hours, months, even years developing your product, not showing it to anyone. It’s because you don’t want to disappoint people with something that’s lacking features. After getting it out to your customers you realize that they either don’t understand it the way you hoped they would or don’t need it (anymore) because in the time that has passed, the market has changed.

Just ship, baby.
— Kent Beck

Instead of having a bad experience, like above, try shipping in smaller bits and steps. Just make sure that those simple bits work to a point that people can try it. You’ll get feedback earlier and you might become aware of things you haven’t thought of to begin with. Don’t be afraid that people might not like what you’ve made.

The most important thing is that you get your ideas out to your customers and validate your assumptions as early as possible.

The earlier you get feedback, the quicker you can pivot your initial idea with less effort and ultimately prevent your team from building something in the wrong direction.

Not enough Pizza

As teams scale up it gets harder to communicate and share knowledge with every single person. People tend to feel less accountable for what they are working on and devalued as the team grows. Luckily for us, there is a good rule of thumb for team sizes:

If you can’t feed a team with two pizzas, it’s too large.
— Jeff Bezos

Depending your appetite, that usually makes teams range from 5 to 7 people.

The term two-pizza team was originally coined by Amazon’s CEO Jeff Bezos while he transformed the company’s product teams into small, autonomous, cross-functional, working task-forces.

Focus, communication, commitment, responsibility and self-coordination. All those principles become effective throughout each team member in smaller teams.

You can read more about Amazon’s two-pizza teams in this FastCompany article.

Team Management with Emails

Communication between distributed team members can be a real challenge. If you have to work remotely, email collaboration is usually not the best way to be productive. Chatting and making Skype- or phone calls already improve communication. But the most effective and best way for remote teams to communicate is still a video call (Hangouts, Speak.io) where both ends focus on the conversation and try to look into each other’s virtual eyes.

@gclaps and me syncing via video call

Just last week, somebody told me that they’re doing video calls regularly. They went on to say if the person they’re talking to makes eye contact while speaking, it feels like a real conversation. Here, the focus is strong and there is almost no loss of information.

“Lean sounds nice, but it doesn’t work for the enterprise”

Bill really inspired me by saying he’s applying the principles of lean into PayPal’s enterprise environment. He started to work on one pilot project with a cross-functional team, applying new habits and principles, then went on with the next team for the next project and so on.

Slowly but surely lean thinking and the culture of the lean methodology was understood and adopted, with advantages being uncovered as teams find their own rhythm of development.

Especially in complex and settled environments, start with a pilot, learn and iterate.

Going dark

For example, if one member of a team is working 5 days in a row on their own, shutting down to focus on their own tasks, collaboration with the team will obviously not be as intense as it could be if that team member was to exchange thoughts in shorter and regular intervals.

Communication and knowledge sharing is key for a good playing team.

Lack of communication can lead to team members doing things twice or leaves them unaware of product changes that might happen while working without communicating with the rest of the team. Further, big chunks of work are already wired too complex to fix without much effort.

A healthy communication culture is crucial for (remote) product teams to stay in sync. Without it, it’s impossible to react to sudden changes or to go after new opportunities. Regular Stand-Up Meetings can help a lot with that.

The Naysayer

If you are the type of person who is really visionary about future implementations, or features in your project or product, you know that your stream of ideas is never-ending. When it then comes to the point to share the idea with your team and there is someone who brings up half a dozen reasons that your ideas are not convertible or simply far-fetched, it seriously decreases your and the whole team’s productivity. Assuming that your ideas will be vaporized by the naysayer in any case, it narrows down your motivation to share them.

A reason for the naysayer’s reaction might be, at first sight the idea could be too overwhelming from their point of view. Breaking down the process into smaller steps, and explaining why that feature is important could be an approach to put everyone on the same page, naysayer included. The covert aim is to encourage each team member to be innovative and to come up with great individual ideas that eventually get implemented into the product.

In general, talking about the company culture regularly with the whole team empowers, connects and helps a lot to understand the reason why and how features are being implemented.

Have you made an experience based upon one of the topics mentioned above? Do you know some team productivity anti-patterns everybody should be aware of? I’d love to hear your opinion in the comments!

If you’d like to automatically receive new posts that are all about product, subscribe here to get them via email.

The post 6 Anti-Patterns Every Product Team Should Avoid appeared first on Blossom.

There was one key pattern that I’ve noticed over and over again.

Some companies approach software development as an engineering management challenge. Others approach software development as a product management challenge.

Good companies manage Engineering.
Great companies manage Product.

In most companies (especially larger ones) product management is severely understaffed or doesn’t have enough political leverage.

If you have a super strong engineering team
but a weak or understaffed product team,
you will struggle.

— Fred Wilson, Union Square Ventures

Putting your focus back onto managing product might sound trivial but it makes a profound difference.

Don’t starve Product Management

There is a simple reason why product management isn’t getting as much attention and political leverage as it deserves. Especially when it comes to larger companies and companies with growing pains.

Without sales, nothing would get sold.
Without engineering, nothing would get built.
Without support, customers would leave.
Without product managers? Life would be just fine. (For a while.)

— Kenneth Norton, Google Ventures

Hiring great product people is easy just so easy to forget about as your company grows.

The key thing to understand here is that when you get overwhelmed in engineering management issues this often is just a symptom of a simple root cause.

Your organization has become reactive rather than proactive.

How to regain your grip on Product

Hire people who have a broad background (ux, marketing, engineering, …) and put them in charge of translating vision into strategy, strategy into tactics and tactics into execution.

You want people who are great communicators and who are able to slip into the shoes of many different roles quickly.

Re-shuffle your engineering teams and turn them into cross-functional product teams of about 3 to 7 people. This enables autonomy, increases quality and accelerates your time from idea to delivery.

Clearly set the vision and why you want to go in a certain direction.
Let your product teams figure out what and how to pull it off.

If you found this essay helpful you might want to take a look at our hand-picked product management training resources.

The post Good companies manage Engineering, great companies manage Product appeared first on Blossom.

The good news is, I’m not alone.

Studies show that multitasking isn’t the most productive way to work, yet we still do it.

To my surprise, there’s a great explanation for all of this. It’s called the Zeigarnik Effect.

Getting teams to focus

The Zeigarnik Effect is the psychological phenomena in which:

1. Tasks we start but don’t finish cause us ‘mental dissonance’
2. We easily forget what we’ve completed

We literally cannot stop thinking about things we’ve half-done. In fact, we divert our attention (and celebrations) away from the things we have done, and put it back into the new things we haven’t completed.

Many video games, like Farmville and Destiny, use the Zeigarnik Effect to encourage addictive behavior by always leaving the user with something incomplete. This keeps the user’s minds stuck on finishing their incomplete tasks.

But, as Carl Vikman puts it, while multitasking can seem productive:

doing many things is not the same “as getting things done”

To regain focus, we can do two things to get on top of multitasking:

1. Limit “work in progress”
2. Visualize and celebrate completed work

Work in Progress (WIP) Limits

Unfinished tasks can be a huge energy drain, especially when new work pops up. They also hinder our ability to be creative. Multitasking decreases our focus and makes it harder to navigate our way through complexity.

That’s why being aware of how many things you do at the same time and limiting this makes a massive difference. And it works for both individuals and teams.

I usually tell people if you have a team of four and they are working on ten things at the same time, this means that people are probably working on too many things simultaneously.

Ideally, for your team you will find a “flow-zone” where the amount of work you undertake and your capacity align.

Blossom has a neat way to make sure you’re aware if you’re escaping your “flow-zone”. If you don’t think it is a good idea to work on more than two features at a time you can set your team’s work in progress limit to two.

Whenever you work on more things than you’ve set as ideal (in this case, two) we’ll show you a small indicator to make you aware of the fact that you might be trading focus for fighting multiple fires.

It’s not a hard limit, and that’s on purpose. In the end, the point of a WIP limit is to help you get things done, not to stand in your way.

Make sure to celebrate

Have you ever spent countless days (and nights) finishing up multiple projects to find out you have to begin a new set the very next day? I have, and it’s not fun.

In times like these, it’s especially important to celebrate our wins.

…with celebration comes motivation. And with motivation comes better products. And with better products come happier customers. — Getting Real, Basecamp

Celebrate a shipped feature, a major release or something your team has completed. Visually celebrating our wins help us keep them in our minds. They remind us how far we’ve come and motivate us to achieve more.

Using handcrafted emails, Blossom can notify and remind everyone that a feature was finished. These celebration emails show who was involved as well as how long it took for a feature to be completed. It serves as a visual reminder of how much time and work went into creating a great solution.

Celebrating a shipped feature doesn’t have to stop with emails. Blossom can also send notifications to group chat tools, like Slack, Hipchat and FlowDock.

Our distributed team lives in our chat tool. It’s our shared environment, a virtual headquarters and party location. As a bonus, it also means we get to celebrate achievements using emoticons and shoutouts.

Focus on less and celebrate your achievements

Maintaining focus is a real challenge, yet so incredibly important if you want to deliver high quality.

Working on a few clear things at the same time and celebrating your achievements are key ingredients that make an effective team and enable you to do the best you can.

P.S. Interested in learning more about our team and our approach? Blossom is hiring.

The post How to Focus with Work-in-Progress Limits appeared first on Blossom.

Here are a few lessons learned on what you can do in situations when you find yourself hopelessly strapped for resources & fighting against all odds.

Don’t Panic

Easier said than done — the most important thing is to “don’t panic”. Being stressed out is the worst thing that can happen to you when you need to keep a cool head. It’s never as bad as it seems. Never, ever.

Grab a cup of tea. Go for a walk. Meet fellow product people. Clear your mind. — Clear thought is your main asset.

Embrace Constraints

Everyone is strapped for resources. Let’s repeat that. Everyone. Always. Great ideas come cheap. Resources not so much.

Since everyone is strapped for resources I believe the art rather is to acknowledge that fact and make the best out of it.

“[…] Never found a company that said: We need [to] write down ideas, we probably won’t have any tomorrow or next week.”
— Stephan Schmidt

Constraints spur creativity. They enable you to think outside of the box. They can make you identify things that you never would have discovered otherwise. As cheesy as it may sound — Constraints are an opportunity to do the best work of your life. — embrace them.

Focus, Focus, Focus (Limit Work-in-Process)

Ever tried to figure out how introducing a combination of 20 changes to your product will affect user engagement, market positioning, code architecture and user interface? What if some of the changes aren’t finished in the order you imagined?

It’s tough to get a clear understanding even if your team is full of brilliant talent. Don’t make product management even harder than it already is by doing too many things at the same time.

Multitasking is a myth. Especially when it comes to deliver excellent creative work like some of your main product-related efforts (engineering, user experience, marketing, positioning …).

By limiting work in process not only do you ship things faster … you enable your team to do it’s best job. Less is more.

Less context switching, better understanding of what’s important, fewer dependencies, less coordination needed, fewer defects, fewer bad decisions.

Simplicity, focus and execution quality (or lack thereof …) go hand in hand with the number of things you try to do at the same time.

Some Things are more important …

Not every idea that sounds like a great opportunity is worth pursuing. Remember, ideas come cheap. If you have a ton of great ideas but only time to do a few of them … the best thing you can do is pick the right ones … in the right order.

“In order to do a good job of those things that we decide to do, we must eliminate all of the unimportant opportunities.”
— Mike Markkula, Marketing & Angel Investor at Apple

This is the main lever you have to increase value. Get all stakeholders on board and figure out what the cost of delaying a change looks like over time.

For example when you have a real deadline e.g. integrating a billing system before black friday the cost of delay over time might look like this:

If you don’t do it right now, or next week it’s not a big deal, but if you miss the deadline … suddenly the delay becomes very expensive. Other scenarios are rather intangible like upgrading to a new version of Ruby on Rails. It’s probably a good idea. If you don’t do it by next month you won’t be out of business but delaying the upgrade for too long might become very expensive eventually.

That said, it’s not your job to make the perfect decision and get to 100% understanding of the situation. Just make time to think about it. It’s like playing chess against the clock.

Here are a few examples of how the cost of delay might look in various scenarios.

Always bring the Donuts

When you’re stressed out … chances are other people are even more stressed out … like your team or other stakeholders. As product manager you live on the intersection of engineering, marketing, user experience, sales and many other things.

You are a jack of all trades and literally a master of none — yet your responsibility is to orchestrate. In a sense your job often is to do the things no one really is responsible for and no one really knows how to put into words.

“If we treat people as they are, we make them worse. If we treat people as they ought to be, we help them become what they are capable of becoming.”
— Johann Wolfgang von Goethe

Be pro-active. Be optimistic. Create an atmosphere where people can collaborate and do great things. As a product manager you are in the unique position to do what’s right & needs to be done whether it’s requested or not.

Be humble, be empathetic and ready to go the extra mile — bring the donuts.

Buy Information by Delivering early

If you find a way to reduce the time it takes to get something out of the door it can be a big win. This might mean consciously reducing scope, accepting technical debt or splitting a feature into atomic parts that make sense and can get shipped independently.

This is a powerful concept. In a sense you can buy information by delivering early.

Another take on buying information is to build prototypes, paper mockups or playing around with UI concepts in keynote rather than immediately switching into building mode.

As side-effect you’ll get a better feeling for the real complexity of a feature. By delivering early you can dramatically de-risk what you’re currently working on.

Slow & Steady wins the Race

Haste makes waste. Especially in times when everything needs to get done faster make sure to take your time and don’t rush into things. Think through personas, write great user stories, write a readme.

Work like the tortoise, not like the hare.

Look for Low Hanging Fruit

With every product there are small changes you can make that have high impact. Often they are not written down in your master plan, not present in a backlog and no stakeholder ever asked for them.

Finding low hanging fruit feels very similar to bumping into a treasure chest in an RPG. Low effort, instant awesomeness. Create a culture of collecting low hanging fruit. Make time to stop and unlock value if it is low effort. You win by increasing value. Not by compliance to old plans. Don’t miss the forrest for the trees.

Invest where Technical Debt meets Value

Every software project has technical debt. It accumulates over time. Especially in situations where time-to-market is very important.

Technical debt is not inherently bad. It’s a tool. A trade-off. That said, after some time … working on defects might take up a significant portion of your time. Sometimes even more time than new feature development.This is a great opportunity to take a step back.

Try to identify areas of your product where technical debt meets high value. Be bold. Invest time to improve these parts and you’ll regain the ability to move fast in the most important area of your product.

Technical debt in parts of your product that are used a lot can get very expensive very fast. It affects the volume of support requests, perceived quality and the ability to iterate on your core value proposition.

Being “lean & agile” doesn’t help much if working in your code base feels like walking on quicksand.

That said, fighting technical debt in all parts of your code base usually yields dimishing returns very quickly and comes with high opportunity cost. Keep in mind that technical debt has different characteristics compared to financial debt.

Technical debt in parts that no one cares about is ok. It doesn’t necessarily need to be repayed, it might not even increase over time. Sometimes you can just wait a bit and deprecate parts with high technical debt or replace them with a 3rd party library.

Identify one area in your code base where technical debt meets value and try to figure out what could be done to improve the situation.

Define “Why”

The purpose of what you’re doing constantly gets lost in the day-to-day … yet the essence of a great solution is to deeply understand why you are working on it. Whether it’s engineering, marketing, user experience design, selling — people with purpose can move mountains.

As product manager your main job is to understand context, define purpose and to make sure everyone gets it. Everyone. You, your customers, your team, every stakeholder, all the other teams.

Don’t be afraid to over-communicate … and bring the donuts

If you found this post helpful you might want to follow me on twitter where I tweet about Software Development & Product Management

The post 10 Product Management Hacks for Times when you’re strapped for Resources appeared first on Blossom.

It’s tempting to take on new projects, new features, new geographies, new speaking opportunities, whatever. Each one incrementally sounds like a good idea, yet collectively they end up punishing undisciplined teams. I like to counsel that the best teams are often defined by what they choose not to do.

Let me explain.

As a VC I regularly meet with companies and listen to their plans. It’s a very common occurrence that a young startup with sub 20 staff and sub $2m in financing is racing around doing too many things. This level of complexity always worries me. A significant number of the companies I meet with get some form of feedback from me that:

“I’m a bit worried that you’re doing too many THINGS. You run the risk of being a mile wide and an inch deep. It’s hard enough to do X really well and succeed. I’m not sure how you do all these other things and yet I think they may end up being a distraction to X.”

I already know your response. Trust me. I hear it every week

“Yeah, but I’m just going to execute this [channel sales deal, international license of my product, new industry, new operating system, biz dev deal] and then it will pretty much run itself.”

It never does. That channel deal that you thought would take no times ends up burning scarce calories. The 3rd-party tries to sell your software — they just need your help with tech assistance to close the deal. They just need you to update your marketing materials. They got your last version working but since your latest release they couldn’t get it to work. That test you did on launching a RIM version of your product — it was only beta — now has 20 users who need a patch because it’s not working properly.

Every extra set of features that you added that served one narrow use case end up being features you need to support in future releases adding complexity to future development, usability testing, regression testing, etc.

Every team I fund comes across as laser focused on their core mission.

My advice?

I always tell teams I meet with, “The scarcest resource in your company is management bandwidth. Spend it wisely.”

Every company is built by a team and every team member matters. But as you know, a few key people in any business have disproportionate impact on the company’s ultimate success. And nobody is more important in this regard than senior management. These people need need to be hyper focused on those things that matter the most to the company’s success. It’s why I don’t invest in Conference Ho’s.

Examples from discussions I’ve had this month that might resonate with your internal debates about how to prioritize

• We are giving a version of our product to a team in Europe who will start selling our product internationally
• We are signing up a channel partner to sell our product since we haven’t scaled our internal telesales team yet [yes, we know that they don’t have experience selling IT, but they have customer relationships]
• We’re going to put a guy on the ground in the UK to address early leads we’re getting from ad agencies there [true, we haven’t thought about employment laws, taxation, currency management, etc.]
• I know our product seems complex but we felt we needed to test lots of features to be sure we knew what would resonate with users … or … we aren’t committed to features x, y, z yet but we know our competitors are planning to so we wanted to be first to market
• We need to hire a team in financial services now to address the needs of that industry [yeah, I know we don’t yet have big customers there. ok, I know our product isn’t yet verticalized. still, we need to start now or we’ll be behind.]

And so on. Trust me — each additional complexity you add before you’re ready decreases your probability of being truly excellent at the things you want to do extraordinarily well.

Instagram didn’t rush to Android. They also didn’t do video. They were truly excellent at what they did do.

What do you want to excel at? How will today’s “toe in the water” initiatives distract you or take your management’s time or attention off of your core business? How likely is your, “won’t take too much time” initiative to come back and bite you in the butt?

Beware. The best teams are hyper focused.

The post The Scarcest Resource at Startups is Management Bandwidth appeared first on Blossom.

Product managers: One of the toughest and worst defined jobs in tech

The role of “product manager” “program manager” “project manager” is one of the toughest, and worst defined jobs in tech. And it often doesn’t lead to good products. The various PM roles often have no direct reports, but you have the responsibility of getting products out the door. It often becomes a detail-oriented role that are as much about hitting milestones and schedules as much as delivering a great product experience.

Thus PMs sometimes end up in the world of Gantt charts, 100-page spec documents, and spreadsheets rather than thinking about products. Now, all the scheduling and management tasks matter, but it’s too easy for PMs to lead with them rather than leading with products first.

Bad ideas are often good ideas that don’t fit

In the context of literature, books, and newspapers, it’s the job of the editor to pick the good stuff and weave it into a coherent story. You remove the bad stuff, but “bad” can mean it’s a good idea but just doesn’t fit into the story. It’s a compelling and important distinction for consumer internet.

Cohesion and consistency is difficult. When you have an organization with lots of very smart people all with their own good ideas, it’s difficult to decide which path to take. So often, products are compromised as the product “manager” doesn’t feel the responsibility to build up that cohesion as an ends in itself, and instead just tries to do as much as possible with the product given some set timeframe. Focus, people!

Jack Dorsey in his own words

In a recent talk at Stanford, Jack Dorsey describes his idea of editors:

“I’ve often spoken to the editorial nature of what I think my job is, I think I’m just an editor, and I think every CEO is an editor. I think every leader in any company is an editor. Taking all of these ideas and editing them down to one cohesive story, and in my case my job is to edit the team, so we have a great team that can produce the great work and that means bringing people on and in some cases having to let people go. That means editing the support for the company, which means having money in the bank, or making money, and that means editing what the vision and the communication of the company is, so that’s internal and external, what we’re saying internally and what we’re saying to the world – that’s my job. And that’s what every person in this company is also doing. We have all these inputs, we have all these places that we could go – all these things that we could do – but we need to present one cohesive story to the world.”

A video of Jack Dorsey talking about the concept can be seen here:

Lead with product

What’s compelling to me about this is that it really orients the role of product to be about cohesive experiences first and foremost. OK, yes, there’s still schedules first, but it doesn’t drive the thing – great products drive the process.

Similarly, you don’t just jam lots of characters and plot points in a story just because. Even if they are good characters, it can bloat the story. Same with features – sometimes you have many, many good ideas for your product, but if you come to do all of them, you ultimately make it a confusing mess. Instead, you have to “edit” down the feature list until you have a clean, tight experience.

Anyway, I hope to see this trend continue in the tech industry – it sets the right tone for where we should all be focused.

The post Why Companies should have Product Editors, not Product Managers appeared first on Blossom.

”Concurrent software development means starting development when only partial requirements are known and developing in short iterations that provide the feedback that causes the system to emerge. Concurrent development makes it possible to delay commitment until the last responsible moment, that is, the moment at which failing to make a decision eliminates an important alternative. If commitments are delayed beyond the last responsible moment, then decisions are made by default, which is generally not a good approach to making decisions.”

Paradoxically, it’s possible to make better decisions by not deciding. I’m a world class procrastinator, so what’s to stop me from reading this as carte blanche? Why do today what I can put off until tomorrow?

Making decisions at the Last Responsible Moment isn’t procrastination; it’s inspired laziness. It’s a solid, fundamental risk avoidance strategy. Decisions made too early in a project are hugely risky. Early decisions often result in work that has to be thrown away. Even worse, those early decisions can have crippling and unavoidable consequences for the entire future of the project.

Early in a project, you should make as few binding decisions as you can get away with. This doesn’t mean you stop working, of course – you adapt to the highly variable nature of software development. Often, having the guts to say “I don’t know” is your best decision. Immediately followed by “… but we’re working on it.”

Jeremy Miller participated in a TDD panel with Mary Poppendieck last year, and he logically connects the dots between the Last Responsible Moment and YAGNI:

”The key is to make decisions as late as you can responsibly wait because that is the point at which you have the most information on which to base the decision. In software design it means you forgo creating generalized solutions or class structures until you know that they’re justified or necessary.”

I think there’s a natural human tendency to build or buy things in anticipation of future needs, however unlikely. Isn’t that the Boy Scout motto – Be Prepared?

As a former Scout myself, I think we should resist our natural tendency to prepare too far in advance. My workshop is chock full of unused tools I thought I might need. Why do I have this air compressor? When was the last time I used my wet/dry vac? Have I ever used that metric socket set? It’s a complete waste of money and garage space. Plus all the time I spent agonizing over the selection of these tools I don’t use. I’ve adopted the Last Responsible Moment approach for my workshop. I force myself to only buy tools that I’ve used before, or tools that I have a very specific need for on a project I’m about to start.

Be prepared. But for tomorrow, not next year. Deciding too late is dangerous, but deciding too early in the rapidly changing world of software development is arguably even more dangerous. Let the principle of Last Responsible Moment be your guide.

The post The Last Responsible Moment appeared first on Blossom.

I started my career as an engineer and advanced pretty quickly into engineering management. During the bubble, I probably hired over one hundred engineers. I learned a lot about hiring, mostly by making mistakes. When I transitioned to product management I was able to apply some of my experience hiring technical people, but I also learned a whole new set of lessons. Last week a friend called to say he needed to hire a product manager and wanted my advice. I realized there’s not a lot of good information out there about interviewing PMs (there’s not a lot of good information about product management in general). More to the point, there’s not a lot about what you should look for in a product manager no matter what kind of environment you’re in – startup or big company. So I thought I’d pull together some of what I learned.

Remember buddy, nobody asked you to show up

Product management may be the one job that the organization would get along fine without (at least for a good while). Without engineers, nothing would get built. Without sales people, nothing is sold. Without designers, the product looks like crap. But in a world without PMs, everyone simply fills in the gap and goes on with their lives. It’s important to remember that – as a PM, you’re expendable. Now, in the long run great product management usually makes the difference between winning and losing, but you have to prove it. Product management also combines elements of lots of other specialties – engineering, design, marketing, sales, business development. Product management is a weird discipline full of oddballs and rejects that never quite fit in anywhere else. For my part, I loved the technical challenges of engineering but despised the coding. I liked solving problems, but I hated having other people tell me what to do. I wanted to be a part of the strategic decisions, I wanted to own the product. Marketing appealed to my creativity, but I knew I’d dislike being too far away from the technology. Engineers respected me, but knew my heart was elsewhere and generally thought I was too “marketing-ish.” People like me naturally gravitate to product management.

1. Hire all the smart people

So what do I look for in a PM? Most importantly, raw intellectual horsepower. I’ll take a wickedly smart, inexperienced PM over one of average intellect and years of experience any day. Product management is fundamentally about thinking on your feet, staying one step ahead of your competitors, and being able to project yourself into the minds of your colleagues and your customers. I usually ask an interview candidate a series of analytical questions to gauge intelligence and problem-solving ability. Generally I’ll ask questions until I’m sure the candidate is smarter than me. For some reason, lots of people I know are reluctant to do that. They argue that it’s insulting to the candidate. I think the right candidate will relish the challenge. In fact, that’s the first test – how do they react when I say “I’d like to pose some theoretical problems, is that okay?” The best of the bunch are usually bouncing out of their chairs with excitement. The super smart sometimes counter with questions of their own.

2. Strong technical background

Some managers I’ve known insist on hiring only PMs with computer science degrees. I’m not as snobby – maybe it’s my own liberal arts undergraduate education – but I do tend to favor people who’ve been in technical roles. Having a solid engineering background gives a PM two critical tools – the ability to relate to engineers and a grasp of the technical details driving the product. It depends on the product of course – a PM working on low-level developer APIs is bound to need more technical chops than one working on the front-end of a personals web site. But the basic principle applies – product managers with technical backgrounds will have more success conveying product requirements to engineers and relaying complicated details to non-technical colleagues and customers. That said, there are pitfalls you need to avoid. Most importantly, a PM who’s a former engineer needs to realize that he or she is just that – a former engineer. PMs who come from engineering and still try to take charge of technical decisions and implementation details will crash spectacularly. For that reason, I like hiring technical people who’ve already made the move to product management at a previous job. They’ve already gone through the challenging adaptation period and by checking references you can get a feel for how well they’ve evolved. I won’t bore with you with interview questions to evaluate technical competency. They depend on the skill set and there are hundreds of web sites that give good tips for hiring engineers. Instead, here are some good questions for gauging how well a technical PM has adapted to the role and their ability to work with engineers:

• Why did you decide to move from engineering to product management?
• What is the biggest advantage of having a technical background?
• What is the biggest disadvantage?
• What was the biggest lesson you learned when you moved from engineering to product management?
• What do you wish you’d known when you were an engineer?
• How do you earn the respect of the engineering team?

3. “Spidey-sense” product instincts and creativity

This next category is highly subjective, difficult to evaluate, and extraordinarily important. I am a strong believer that certain people are born with innate product instincts. These people just know what makes a great product. They’re not always right, but their instincts usually point in the right direction. They tend to be passionate advocates of a point of view, sometimes to the chagrin of their colleagues. I’ve had the good fortune to work with a good number of these people, and it’s an essential trait in product managers. And it can be tuned, but it can’t be learned. Product management, especially in highly dynamic environments like the web, involves lots of small decisions. Sure, there’s a lot of big thinking and strategy. But it’s the little decisions where a great PM distances him or herself from a decent one. You know they’ve got the “spidey-sense” product instinct when they suggest approaches that nobody on the team has thought of, but immediately strike everyone as obvious when they hear them. Evaluating product instinct in an interview is challenging at best. But it can be done. One thing I always do is check to see if the candidate has accomplished the following tasks during a one-hour interview:

• Independently echoed some of my own concerns about my product – if you’re a good PM, you’ve got a bunch of things that worry you about your own product. Maybe they’re UI shortcomings, missing features, or architecture flaws that need to be addressed. They’re things you know need to be fixed. At least some of these should be obvious to an intelligent outsider with strong product instincts. I look for that moment in the interview when I smile, nod, and say “yeah, I know – that’s been driving us crazy too.”
• Taught me something new about my product – it could be an obvious improvement that I’d never considered, a new idea for positioning against a competitor, or a problem they encountered that needs to be addressed. When I learn something from a candidate, I know two things: (1) they’re not afraid to speak critically, and (2) they’re probably smarter than me. I want both in a product manager.
• Turned me on to something new and interesting – people with great product instincts tend to notice great products before everyone else. If I’m interviewing a top-notch candidate, I usually walk away having discovered something new and innovative.

Here are some good questions for judging product instincts:

• Tell me about a great product you’ve encountered recently. Why do you like it? [By the way, it drives me crazy when candidates name one of my products in an interview. I had a hard time hiring anybody at Yahoo! who told me the coolest product they’d come across recently was Yahoo! Good grief.]
• What’s made [insert product here] successful? [I usually pick a popular product, like the iPod or eBay, that’s won over consumers handily in a crowded market.]
• What do you dislike about my product? How would you improve it?
• What problems are we going to encounter in a year? Two years? Ten years?
• How do you know a product is well designed?
• What’s one of the best ideas you’ve ever had?
• What is one of the worst?
• How do you know when to cut corners to get a product out the door?
• What lessons have you learned about user interface design?
• How do you decide what not to build?
• What was your biggest product mistake?
• What aspects of product management do you find the least interesting and why?
• Do you consider yourself creative?

4. Leadership that’s earned

Product managers are usually leaders in their organizations. But they typically don’t have direct line authority over others. That means they earn their authority and lead by influence. Leadership and interpersonal skills are critical for product management. There are a thousand books about leadership, so I won’t turn this post into a treatise on the subject (most of the books are crap anyway). I find reference checks to be the most effective way to measure leadership skills, especially references that involve peers and individual contributors who worked with – but did not report to – the candidate. But here are a few questions I’ve used in the past:

• Is consensus always a good thing?
• What’s the difference between management and leadership?
• What kinds of people do you like to work with?
• What types of people have you found it difficult to work with?
• Tell me about a time when a team didn’t gel. Why do you think that happened, and what have you learned?
• How do you get a team to commit to a schedule?
• What would somebody do to lose your confidence?
• Do you manage people from different functions differently? If so, how?
• What have you learned about saying no?
• Who has the ultimate accountability for shipping a product?
• Have you ever been in a situation where your team has let you down and you’ve had to take the blame?
• How has your tolerance for mistakes changed over the years?
• Which do you like first, the good news or the bad news?
• What’s your approach to hiring?

5. Ability to channel multiple points-of-view

Being a product manager requires wearing multiple hats. I often joke that much of the time your job is to be the advocate for whoever isn’t currently in the room – the customer, engineering, sales, executives, marketing. That means you need to be capable of doing other people’s jobs, but smart enough to know not to. Great PMs know how to channel different points-of-view. They play devil’s advocate a lot. They tend to be unsatisfied with simple answers. In one conversation they might tell you the requirements don’t seem technically feasible and in the next breath ask how any of this will make sense to the salespeople. There’s one obvious way to evaluate a candidate’s ability to think through a problem from multiple angles – gets lots of people in the interview process. I always insist that at a minimum, representatives from engineering, design, and marketing meet a potential PM candidate. Depending on the specific role, this list can grow – pre-sales engineering, support, developer relations, business development, legal, or customers themselves. Ultimately anyone who will be working with this person should meet them. Note that I didn’t say everyone needs to meet them. One carefully selected representative of each key function will suffice. And it also doesn’t mean everybody has to give a thumbs-up – it’s hard to build consensus in an interview process as the list of interviewers grows, so consider the feedback appropriately. But nobody will be able to judge how well a product manager understands the sales process like a salesperson. I also strongly recommend that you give specific instructions to the interviewers, like “I’d like you to see how well this person would understand the issues you face in channel development, and how we’ll they’d support you in the field. “Here are some specific questions that I use (these are just examples, feel free to replace the functional names):

• How have you learned to work with sales?
• What is the best way to interface with customers?
• What makes marketing tick?
• How do you know when design is on the right track?
• How should a product manager support business development?
• What have you learned about managing up?
• What’s the best way to work with the executives?

6. Give me someone who’s shipped something

This last characteristic may be the easiest to evaluate. Unless the position is very junior, I’ll usually hire product managers who’ve actually shipped a product. I mean from start to finish, concept to launch. Nothing is a better indication of someone’s ability to ship great products than having done it before. Past performance is an indication of future success. Even better, it gives something tangible to evaluate in a sea of intangibles. When checking references, I always make sure to talk to important colleagues from a previous project, especially the PM’s manager and their engineering and sales or marketing counterparts. (Incidentally, these rules are ordered for a reason, and as I mentioned under #1 I’ll still take a brilliantly smart PM over a dimmer experienced one even if the former hasn’t shipped before).

Note: I wrote this in 2005 when I was at JotSpot. Google acquired JotSpot in 2006. Since then, I’ve had the opportunity to work with some marvelous PMs and have performed 200+ PM interviews. I’m sure that my opinions have evolved, but the intervening years have only further reinforced the characteristics of great PMs. I occasionally set out to update this essay but I always decide to leave it as is. (—Ken, February 2013)

The post How to hire a Product Manager appeared first on Blossom.