The structure of modern business forces people to become stale as they age.

The economic incentives of most creative industries, including tech, all point in this direction. When you are young, you *make* stuff. You code, you design, you write, you execute. You constantly get to practice and improve your making skills.

The normal definition of success implies moving up the management chain. You become “strategic”, which brings leverage to the business, and as a consequence you focus more on managing and mentoring people rather than making.

You gain wisdom about people, but your wisdom about your craft ossifies. You can edit work output, but you aren’t creating it. You can spot and foster “maker” talent, but the phrase “maker” doesn’t apply to you anymore. And frankly, without constant practice, your basic making skills suffer. This in turn could threaten your decision-making ability.

Your younger hires think of you as a “suit”, even if you don’t wear one. And here is the saddest part: most of us got into our creative field of choice because of the pleasure of making things. My hypothesis is that many creatives find their work less enjoyable as they increase in seniority, even though they take pleasure in mentoring and managing.

This is an endemic structural problem. I’m not sure how it can be solved, but it would require changing how we value different capabilities and affect the very structure of organizations.

At a personal level, the only way I know to break out of this is to force it. This does not come free. It takes sacrifice.

If you are serious about defeating management ossification:

- start a pet project but commit to a serious time investment
- start a company and get back into the trenches *
- become a freelancer
- re-negotiate what your job entails

You not only need to make something new, but you need to try out fresh methods as well.

It will be frustrating. You will be rusty, so you won’t be as good or as fast as you remember. But it is pretty amazing when you can combine years of experience with fresh making skills. You’ll soon realize that you can run circles around your younger self.

* in my case, I started two. First, a product startup which I shut down after a year, but which was like a rebirth. Then a consulting business, which I sold and which I am currently helping to grow, albeit with the personal mandate that I get to mix some “making” time in with my management duties.

I’ve started curating a “zine” called Product Theory which covers my favorite articles on the broad topic of making great software products (design, management, coding, business models, lean / agile, etc).

Product Theory began life as a Flipboard magazine, but thanks to the magic of IFTTT, you can also access the links at http://ProductTheory.com and Twitter.

I’ve had all my sites hosted on a shared server with a bunch of friends for years, and the decision was made to call it a day on that box. My goal had been to redo this blog in Middleman or Octopress, but the time never materialized, so I’ve done a rush port of the wordpress blog to a new hosting provider. I gather there were a bunch of errors earlier and hopefully those are fixed. Tweet me at @giffco if you are still seeing problems. Thanks and I hope to soon get back to working through a backlog of post ideas.

The other week, I was saddened to learn that Google Reader is shutting down.  While it feels like much of our industry has switched to Twitter for discovery, I still like following “voices”.

Amidst the various reactions to Reader’s demise, the most thoughtful response came from from Vin Vacanti:

Glad google reader shutting down. They weren’t improving it and now door open for someone else to build a better RSS reader

— Vinicius Vacanti (@vacanti) March 14, 2013

While I had a lot of loyalty to Reader, I agree with this sentiment. In truth, I had switched all of my “reading” to Flipboard, so I might as well manage my feeds there too.

Products have natural life cycles. Sometimes they die because the owner no longer invests in it, or because a major platform shift takes the owner by surprise. Sometimes they die because the customer base fights against change. It takes both investment and an appetite for risk to keep them alive.

The nice thing about our industry is that it continually renews. If there is value to offer a customer, someone will find a way to deliver.

Back-End Thinking Getting in the Way

Over the last 3 years, I’ve worked on becoming more comfortable with modern tech stacks, starting on the front-end and moving to the back-end.

Last week, I noticed a problem when I was doing some collaborative design: I was letting the data model influence my design thinking.

i.e. my brain was taking the components of the application and dwelling on the back-end implementation structure. I was horrified, because it could lead to bad UX decisions. I needed to be entirely divorced from those constraints. I needed to focus on how the customer needed to parse and manage the application’s information.

In theory, I could get so fluent with both coding and design that this problem goes away, but that is unlikely to happen.

The lesson is not to avoid learning to code. On the contrary, becoming fluent in CSS and semi-passable in Rails has been extremely useful to me as a product person. But I have realized that I need to very clearly and explicitly switch certain parts of my brain ON and OFF depending on what I am doing.

Why I Never Sketch in Code
A lot of people talk about sketching in code these days. For me, this is a terrible idea for the same reasons as the above. If I am writing CSS, my brain is split between the design issues and the syntax. I want to start by focusing exclusively on what and why.

I would rather sketch in pencil and quickly explore different paths (including responsive permutations), choose a direction, and then implement it. Sometimes there are even more intermediate steps, depending on context. Sometimes wireframes or high-fidelity mockups do actually make sense for internal communication and external testing (i.e. process needs to flex to the needs at hand). Of course, even when I do shift to implementation, I still need to keep the design-side of my brain active because problems and improvements will inevitably pop up.

…

I’m a huge believer in people expanding their skillsets. It is very healthy for digital designers to learn to code. After all, it is the medium with which we work. My personal lesson: be self-aware of your mental state as you work on different kinds of problems, because it can get in the way.

I fear a general misconception out there that you can validate a startup in just a few weeks. I have been particularly pained by both non-coder startup founders and managers at big companies who think that all they need to do is pour money into a single MVP and they’ll have a binary answer as to whether something is awesome or terrible. (note: when I use the term MVP, I mean an actual product, not an experiment)

If you do not have the budget and runway to iterate an MVP and run through multiple build-measure-learn cycles (tip: you should always start with “learn”), all you really are doing is playing the lottery.

Even if an idea is truly solid, in 99% of the time, you still won’t have product-market fit after an MVP. This stuff is not that easy.

What an MVP definitely gives you is essential learning and market signals, and hopefully an important initial foothold in the market.

If you don’t have the determination and ability (budget) to iterate, I don’t really believe that it is worth starting in the first place.

The Lean UX book arrived on my iPad last night, and I’ve just finished reading it cover to cover. I thought it was great.

That judgement is not actually because I work with the authors Jeff Gothelf and Josh Seiden. I find most business books to be pretty banal, and I promise you that I would just stay silent if I didn’t really like the results here.

Lean UX is a great read for any product person — whether they call themselves a UX designer, product manager, dev manager, whatever. This is about approaching product in a better way, not just UX.

The book effectively balances strategic and tactical. There are some very actionable things you can take away from the book and try to convert to your particular situation. It is also nicely concise, and doesn’t fall into the trap of repeating itself over and over (the curse of many a business book).

If nothing else, you should pick up the book to understand the core principles behind Lean UX, and evaluate if they could/should work for your context:

- cross-functional teams (small, dedicated, ideally co-located)
- problem-focused teams
- progress = outcomes, not output (i.e. results over features)
- removing waste
- small batch sizes
- continuous discovery and learning
- getting out of the building
- shared understanding
- team over rockstar
- externalizing work (including communicating up and across org)
- making over analysis
- learning over growth
- permission to fail

Conclusion: definitely two thumbs up from me. Go get it if you haven’t already.

“Why ‘Hire Slow, Fire Fast’ Is A Bunch Of BS,” or so says Danny Boice in a recent Fast Company article that was sent my way.

Well, it is a catch phrase, and as such, has to be catchy and over-simplified.

“Hire as quickly and carefully as you can without screwing your business objectives, and also fire as quickly as you should,” is a pretty banal tweet, isn’t it?  BTW, hiring carefully is not the same as waiting for perfection.

Now, Danny is a smart guy, and he writes a fun, opinionated article, but to riff for a second:

Here’s what is easy
- awesome teammates
- obvious duds

The first, because they are awesome.
The second, because you can spot the poor fit within a week or two and part ways right away, usually letting everyone save face (i.e. everyone just agrees to call it a consulting gig).

Here’s what is hard
- people who are ok but not great

They seemed awesome when outside of your walls, but inside, they are decent but not great. It is harder to fire these people fast. Is it them, or you? Perhaps they just need a bit more management attention? better feedback? time to get up the learning curve or settle in? And, since they are not a total wash, and given that everyone on the team is overstretched even with this person, it becomes hard to imagine going back to one less pair of hands.

So you give them a longer runway, and all of a sudden 4 months zoom by. And having that B-player on the team has a subtly corrosive effect on the morale and effectiveness of your A-players. But now you have to be even more careful with the legal side of firing, which slows things down further. And now firing them is harder on everyone because the B-player is probably very nice and the team has bonded, even if they know the person isn’t the best fit.

There’s another over-simplified cliche that holds some truth: “A players hire A players, B’s hire C’s, and C’s hire D’s”. It is another reason why B’s are troublesome in high-growth enterprises where you have to scale aggressively.

Over the years, I have gotten more careful about hiring, and faster at firing. I’m also really careful about picking co-founders. That doesn’t mean that I can’t move really fast when the fit seems obvious. Nor is that the same thing as waiting for perfection, because none of us are. Every candidate search is a balance between market supply and demand, your constraints, your goals, and your own urgency.

Ross Popoff-Walker asked me on Twitter, “What do you feel is the key difference between a UX Designer and a Product Designer?”. The answer, of course, depends on whom you ask.

I use a very expansive definition of the word “design”. Pretty much everything is a design decision.

UX, like “product management”, is loosely defined in our industry, but to me the term implies things like application flow, motivation loops, interactivity, core layout or visualizations, information hierarchy and structure, and usability. Product design, however, is even more sweeping.

If we’re thinking holistically, every software product needs (in no particular order):

• Front-end development
• Back-end development
• Words / content
• Product management
• UX design
• Visual design
• Customer acquisition
• Metrics analysis
• Sys ops

Those roles can be spread out or combined in multi-functional people. I really like multi-functional people.

No matter what, every product needs a single “product owner” who feels an acute responsibility for the success of the whole. They can be anchored in any of the above categories (i.e. can be a designer, dev, PM, whatever), but it is important for them to be able to relate to others, prioritize  things objectively and not just favor their speciality, and effectively communicate  about issues that fall outside of their areas of expertise.

Everyone on the team is hopefully acting as a “product designer”, but the more they are thinking holistically, as well as doing their specific tasks with excellence, the more they deserve that description.

Innovation fails until it succeeds and, if you are running a corporate innovation team, you have to let that process happen.

While there is a huge desire to measure *everything* these days, I don’t think that corporate innovation programs can be judged based on short-term metrics. Their ideas and the progress of those ideas should be judged, but not the program itself.

Instead, they should be judged based on the rigor of their process, i.e. rigorous at the micro-level, but with air-cover and a patient runway at the macro-level.

You must measure progress, but innovation is not linear, as much as we would like it to be. Progress can lead to dead-ends, which require backtracking, re-starting, or flat-out killing a concept. Senior executive support must buy into this concept at the start.

It is hard to talk about validation and progress instead of shiny visions and cool products. It is easier for an executive to fund a concrete output, like a spec for an iphone app, rather than a vision with malleable features, experiments, and a hunt for product-market fit.

Increasing the odds of success in an corporate innovation program means accepting this hunt, even while enforcing a lean, reality-checking rigor. Unfortunately, I keep on seeing corporate innovation programs that either don’t have the air cover they need, or they are stuck building inside the ivory tower, iterating based on executive whim rather than market and customer realities.