Don’t Create a Blob

An overly general design says to the world “We do not know who our customer is and how they will use this product.” Rather than doing the hard work of experimenting and making a choice when instead gave the customer many choices. Over generalizing makes your product both muddy and overly complicated. A friend of mine, Chris White, used to call overly general products an “Amorphous Morass of Human Insensitivity.” Have you ever used a product that was “powerful” but doing anything with it was very “complicated?” I mean so complicated that it hurt your brain? That product was an Amorphous Morass of Human Insensitivity.

Note that generalization is not bad thing it’s just that you need the right amount. A platform, programming language, or automation tool clearly needs to be more general than a photo sharing app. You will know you are crossing the line when you make simple task a little more cumbersome for a specific user in order to allow more fringe use cases that “might appeal to a larger set of users.”  You might say “While 80% of our customers use workflow A we have a significant 20% of customers that use workflow B and C.” So your answer to this issue is to make your product model ALL workflows. How cool is that? It is totally customizable. No not really cool. You just made life more difficult for the 80% that use workflow A. You could have made something very intuitive and amazing for that 80%, but instead you chose to make something that is just kind of okay for everyone.

Over generalizing can also lead to feature bloat where you have many ways to do the same thing. This leaves your user wondering which way is the appropriate way to carry out a task. Now they have to think, do I use approach A or approach B, C, or D? Don’t give them lots of ways to do the same thing, invest in finding out the most intuitive way and give them that. Give them the right way to do things.

What is my product’s special purpose?

As an old-school object oriented programmer I always wanted to make my architectures as generalized as possible. If I was building an application for categorizing music I could see that I could build it in a way that allowed the application to categorize pretty much anything. Once you fall down this rabbit hole you start doing all kinds of crazy things. For example, you might make the workflow around categorizing music just a little more cumbersome so that it could also be applied to images or documents or “Hey, man” pretty much anything else you might want to categorize! How cool is that?!?” Not really that cool at all. “This architecture is so cool you can pretty much do anything you want to with it!” No, the architecture is sad. Very sad for those customers who wanted an innovative and intuitive way to categorize music.

Product designers and developers do this when they do not understand the unique purpose of the application they are creating. They don’t have 100% certainty that they have a good value and how to deliver that value. So they start adding in a bunch of unnecessary and overly general stuff. Creating few very well defined personae and context scenarios solves this problem. The culture should be that if a use case does not serve an agreed upon persona then it is not added and if a use case is not present it is not considered. If you have a compelling new use case that does not have a persona then you have a business decision to make. You are making a decision to appeal to a new customer or user. You are essentially going into a new market. Don’t do everything you “could” do. Find your special purpose but don’t be a feature slut.

You have to make choices

Let’s say that you have a systems management tool. You know that your users need a better way to manage their nodes. So you hypothesize that you should have a node tagging feature. Great. So far so good. While validating this hypothesis you find that one or two high profile customers really prefer hierarchical grouping for organizing their nodes. What should you do? If your answer is to add the ability to do both then you have answered incorrectly. Answering YES is a step towards creating an Amorphous Morass of Human Insensitivity. New users will wonder, should I use groups or tags? Every feature that targets nodes will need to be done with both “grouping” and “tagging” features. Not being able to say no is a lack of commitment that impacts your customers as well as your development effort. Now you’ve confused your primary customer and you have twice as much code for your developers to maintain. Forget about grouping and deliver a kick-ass tagging feature.

Product Managers love to add features when they don’t want to do the hard work of finding a specific and powerful value for their product. It’s much easier to create a backlog with a bunch of customer requests for “additional features” than it is to figure out the single strategic value and then put all the wood behind that arrow. In music it’s easier to riff on a theme than it is to create a new theme from nothing. But adding too many riffs or layers on a theme will eventually kill it. If you keeping adding features to your product you will eventually ruin it.

You Aren’t Gonna Need It and MVP

YAGNI (You Aren’t Gonna Need It) is a programming concept from XP that is just as important for Product Managers especially when trying to define your Minimal Viable Product. The more features you add without validation the more legacy features you will introduce into your product. The more features you add the longer it will take to release. The more features you add the more muddy you will make your value proposition. Pair down your backlog to just essential features and then take even more features out.

The famous example here is the iPhone. Remember that the first version of the iPhone did not even support cut and paste. As a product manager or owner, how many of you would have made that decision? I think very few. But as a result the iPhone came out quickly and THEN due to customer feedback the feature was added. Determine the features you need for an MVP and then take one away. Not having the so-called essential feature of cut and paste did not prevent the iPhone from being successful.

The first Kodak camera was created for one reason, to sell more Kodak film. However this camera was so simple that it caught on like crazy and transformed Kodak’s business. It was nothing compared to other cameras available at that time. All you could do was point it at something and click a picture. Then you sent the film into Kodak and they developed it for you. There was no F-stop, zoom, flash, etc. Sometimes fewer features give you a more powerful value. Always keep Instagram in mind. This product with very few bells and whistles beyond its primary value proposition sold for a freakin’ billion dollars. Holy shit! Some would even argue that it didn’t have enough features for its value proposition. Find out what features you absolutely need for an MVP and then take some away.

When you find yourself thinking that a product launch was not successful because some essential feature was missing remember the iPhone, Kodak camera, and Instagram. You are really just trying to make yourself feel better for not finding your product’s special purpose. It was not the lack of features that kept your product from achieving revenue goals. It was that you did not find a winning value proposition. Value, not features.

When you don’t have a clear value you need all the features in the world. When you have a well defined value you hardly need any features. If you find yourself adding a bunch of essential features consider if you really have figured out your value.

10 or so Signs that R&D is Sick

A lot goes on in a business but this is about R&D. You should read this even if you are not part of an R&D organization. Sometimes someone outside of the R&D organization needs to spot the insanity because those in the shit in R&D can become too subjective.

Whether you are just starting out or growing an already successful company there are fewer things more destructive to company growth than a sick R&D organization. All parts of your business are important and clearly you need a great idea that speaks to a market but in this post I am going to focus on your R&D organization.

Over the years I’ve observed some traits that may indicate your R&D organization needs a health check. Some of these rear their head right after you’ve had some success and feel you need to “improve” and “grow” your R&D organization. I’m unique, so some of these may make you bristle or you may think I’m insane. Fine, but I know what works and I know what doesn’t work. These are in no particular order. I’ll try to expand each one of these into their own blog post.

1. Process over Productivity

Concentrate on producing not on process. Managers will often work on process rather than address the real problems. I don’t know why, they just do. Working on process makes them feel more important and like they are doing stuff. Process will not make up for a lack of talent, direction, customer validation, and vision. It just allows the VP of R&D to go to executive staff with velocity charts that show R&D is kicking ass even if it is not shipping product and not making customers happy. Have you spent time in meetings talking about the true meaning of a story card and what it should contain? Get a life and start producing and spend less time on silly conversations that probably don’t matter that much. Who cares if story cards vary a little. Optimize the right things. Focus on Product.

2. Technology Centric Architecture

Architecture needs to be customer centric not technology centric. If your engineers are creating overwrought architectures then they need to spend more time with customers and sales. Spend more time coding and designing quick features you can test with customers and less time on a really cool architecture. Perfect features after they have been proven to be valuable. “Build it right the first time” is BS.

3. Managers That Don’t Code Making Technology Decisions

You need leaders not managers. If you have managers that are not practitioners they should not make technology decisions. If they want to make technology decisions then they should also be responsible for doing some coding, designing, testing, or whatever area it is that they manage. If you need a bunch of managers then you may really have a direction and talent problem. Compensate your top individual contributors more than your managers. This will keep them from thinking that managers are more valued and that managing is the only career path in the company.

4. Having a “No Heroes” Attitude

Despite what you’ve heard sports teams and rock bands do have heroes. It’s okay if you do too. People try to emulate heroes and having a hero around raises the bar for everyone else. It’s okay if you have a super star that is peculiar or can be a pain in the ass. Just remember what a super star really is. A super star is NOT someone who can bully other people or quote Knuth. A super star is someone who consistently creates superior customer value quickly. I’m not really a huge Van Halen fan but ask yourself this. Which Van Halen was better? The one with crazy David Lee Roth or the one with the very manageable Sammy Hagar?

5. A Separate Bug Fixing Team

This one always bothers me. At a certain point a company feels that it is too big to have the same people that code features fix bugs in those features. The result is a development team that is out of touch and is not accountable for their mistakes. Trust me, you won’t destroy velocity if the developer that wrote a feature has to fix a bug in it later on or deal with a customer escalation. What you will have is a developer that understand the customer pain they created and be more careful to write solid and usable features in the future.

6. Customer Escalations Stop Being a Top Priority aka Big Strategy Over Customer Satisfaction

This is kind of like the above and it usually comes from the VP or management. At some point a company grows to the point where they believe they have bigger fish to fry than customer satisfaction. If you are going too slow to keep customers satisfied and work on new strategy at the same time then your organization is sick. Find out what’s really wrong in the organization and fix it. There is no better advertisement for a product than word of mouth. There is nothing more important than making sure a customer’s deployment is working. This does not mean creating one off features for customers. Don’t do that! That will give you a directionless product. Know when to say no to one-off customer requests. But do make sure your customers are happy with your product’s intended use. Always make these a priority even if you are a big company with lots of sales. Treat each customer like you did when you were trying to make your first million dollars in annual sales. Remember those days? Remember how horrified you were if a customer ran into a bug that stopped them from using the product? As an engineer you should be embarrassed when a customer hits a show stopper issue. You should not be able to sleep until it is resolved. If you don’t care that you fucked up a customers week then you are either out of touch or a sociopath.

7. The UX Team is Marginalized

Do not marginalize the user experience team. In the best case scenario UX should not even report to R&D but are a peer of R&D and Product Management. UX should be part of the holy trinity that leads a product line — Product Manager, Technical Lead/Architect, and UX. UX are not visual designers. They do not exist primarily to make the product pretty or sexy. They are essential in making sure the product provides value to customers. They run experiments, validate results, and make sure the product is useable and on point.

8. The Engineering Team has no Customer Contact

Make sure your engineers get out of the building. They need to understand the product and its customers not just the code. Once the developers loose contact with the customer things will soon go catawampus. You will have a technology centric architecture that is more than is required. Simple ways to keep this from happening is to send engineers on POC, Professional Services Engagements, on-site escalation resolution, or even sales calls. You could even have engineers rotate on dealing with a technical support issue or two every once in a while. The idea is to have each engineer know how the product is used, what business it is that we are in, and understand the customer pain.

9. The Team is Resistant to Feature Changes

This one is usually a relic from an older style of doing business. You have this when you see R&D asking for detailed product requirements or marketing requirements documents or complaining that the backlog keeps changing. In today’s world businesses (especially start ups) need to change sometimes even day to day based on customer feedback and market changes. Having small units of work that fit into cycles helps with this. If you have engineers complaining that they can’t fit a feature into a cycle then you probably have an over engineered solution. Get features out there quickly, validate them with customers before and after release, and then perfect the ones that have traction. If you are in sprint 3 and the product manager changes the features you were going to do in sprint 4 then the product manager is doing her job. If you are organized so that PM, Architect, and UX form a trinity then they should all understand why the backlog changed.

10. Tension Between R&D and Product Management

The leadership in R&D and the leadership in Product Management should be pals. If they are not pals you will soon see a rift between everyone in R&D and product management. R&D will blame PM for all the ills in the world and product will not get validated and not get delivered because of in fighting and endless debate. An adversarial relationship between R&D and PM could kill a company. R&D needs to believe in what’s it building and PM needs R&D’s support. If you are organized correctly, meaning that each line is lead by a Product Manager, a Technical Lead, and a UX Lead and they are all held accountable then this should not happen. They are team one. In other words, a technical leads primary team should be the Product Manager and UX lead she works with and not the engineering team spread across multiple products or components. Don’t fuck with PM by asking them to specify every last detail of a story. That is old school. R&D, UX, and PM should do that together.

Conclusion

I guess all of these really boil down to just a few points. R&D must be connected with the customer, work in concert with Product Management and UX, experiment with minimal versions of features first, and value productivity over process.