Tag Archives: Product Management

Focus and be productive. A short tale from Pocket.

We always need more people.  I’m the first one in line to say I need more engineers.  And when I get more, I’ll still say I need more.  I will *never* have enough, and I challenge any product manager to say they have enough.
But, consider some of the success stories out there.  And consider the resources each of us have deployed.  We can do a lot.  And we are.  The key is focus on what’s important.  Organize around what’s important and make it happen, potentially at the cost of other things that are (less) important.

Notable quotes:

Remember: getting an app or company on your platform marks the end of a deal, but the beginning of an official working relationship.

There comes a point for every startup when you’ve got to decide between perfection and progression. The first is a stable characteristic and the second is a dynamic conversation. Choose wisely.

How to reward your engineers

As a product manager, I take great pride in my work and getting the job done.  But let me be honest; I do not write the software products I manage.  My engineers do, and they do an awesome job of it.

These engineers do not directly report to me but I am one of their leaders.  I craft the stories they work on to deliver features to market that our customers love and pay us lots of money for.  Without them, I would not have a product to sell nor, a job to pay my bills.  So how do I show my appreciation?

Well, it starts with two very simple words.

Thank you.  

Pretty simple, I know, but it is powerful. James Kouzes‘ book The Leadership Challenge explains in detail how powerful these words can be, as I have stated before.

Often times, verbal appreciation is not enough.  I find I need to do more, simply because I cannot express how thankful I and the company are for the teams’ contribution.  My teams work hard for me and for our customers.  They pull all-nighters fixing important issues that jeopardize customers’ environments.  They sustain long days and nights, including weekends, to get a major feature or new product out.  Throughout it all, they put up with my incessant questions, minor changes in scope and constant feedback, validation and product acceptance processes.  They do, in fact, deserve more.

Pretty regularly, I take small groups of my teams out for lunch, coffee or dinner.  Sometimes we celebrate a particular milestone or accomplishment.  But often times, I am just spending time with the guys, getting to know them and to break some bread together.  I try to pick up the check more often than not, irrespective of whether the company will reimburse me for the team outing.  Part of the successful working relationship I have with my team, and the reason they are willing to work as hard as they do, is because we have a personal relationship founded in more than just “my function requires me to work with you Mr. Product Manager”.  We trust one another, and believe that we have each other’s back.

Some milestones warrant more than a meal.  For those really big feats that move the needle for the company, the words “go big” come to mind.  In the past, I have thrown a party in one instance, and taken the team go-carting in another.  The important part of these activities was to focus on having fun.  We laugh about the insanity of the last few weeks and months in getting our release out the door over food and drink.  At the race track, we had a great time competing with one another for bragging rights on who had the fastest course time.

Maybe it is obvious, but why should I bother rewarding my engineers?  For one, good behavior and actions deserve good things.  From a business perspective, there are compelling reasons to recognize and reward a job well done.  Spending company time and money on employee appreciation nets so many things.  It fosters healthier team dynamics, creating trust and respect.  It energizes employees to work harder knowing that their work means something to someone that they know and can talk to.  Finally, it has other soft benefits including promoting company loyalty and greater overall employee satisfaction.  I strongly recommend all product managers take the time to appreciate their teams’ efforts in building the product they manage.

To MBA or not to MBA?

http://www.linkedin.com/today/post/article/20131002144820-95015-should-i-get-an-mba-entrepreneurial-finishing-school

Good read.  I’ve come across the question a few times in my career thus far.  For the record, I don’t have an MBA.  I do have a graduate degree, though, and that helps me sleep at night.

Do I wonder I’m held back because I don’t have a business degree?  I used to think so.  But instead, I think I’m just not ready to be where I think I should be.  It takes a fairly honest look at yourself to come to this resolution.  “Why haven’t I been promoted?”  “Why didn’t they give me the job they waited 9 months to fill?”  Well, the answer is…”You’re not ready for it.”

Regardless of whether you’re in school or not, there are opportunities to learn in the workforce.  Often, I’ve found myself learning what not to repeat ever again.  But lately I’ve seen more and more examples of things I should emulate in the future.  It will help me get closer to my 5 year goal and what I want to be in business and as a person.

My advice?  Keep at the path you’re on.  If MBA is required for that path, you’ll know pretty quickly, either because you’ll explicitly be told so, or the universe will align and you’ll get into your dream school.  I don’t think you should go get an MBA unless you really need it to be successful and if you don’t get into your dream school.  The cost just doesn’t justify itself otherwise in this day and age.

Another thing to consider is the disruption happening within MBA programs.  More schools are offering 1 year mid-career programs for those who need a booster with emphasis on certain skills they are lacking to make a jump in their career (horizontally or vertically).  I can’t say that the cost is any cheaper, but it’s worth a look-see.

Happy educating!

To innovate you must fail.

My CTO today said that building a product, feature or capability that looks good, but most importantly is useful to solve some problem, is hard.

I know that sounds simplistic.  But it’s true.

Everything that represents significant value is hard to build.  Really hard, in fact.

His key learning in the process to build the feature he demo’ed (if you care – check out Network Manager) was to iterate.

Iteration in my view is synonymous with failure.  You try something once, realize that doesn’t work well (either it isn’t pretty, or it isn’t usable, or both), and then you try again with a different approach.  The “difference” in the two approaches can be small or large, but that’s not really what’s important.  The importance is that you tried, you failed, and yet you tried again.

Jason Seiken at HBS agree with me too.  Failure is a key part of innovation and creating something that’s worth having.

That VP of Eng, Yammer is one smart dude…

http://firstround.com/article/Why-Yammer-believes-the-traditional-engineering-organizational-structure-is-dead

http://firstround.com/article/The-one-cost-engineers-and-product-managers-dont-consider#%23ixzz2WrPaCwIm

Read those links, you won’t be sorry, particularly if you’re in software development or product management.

What is change?

The following are thoughts reflecting my impressions after reading Penelope Trunk’s latest.

What is change?   What is progress?  Does progress mean we stop worrying about things that are currently stressing us out?  Or does it simply mean that we start worrying about things that we don’t consider yet to be stressing us out?

In Penelope’s article, she says that you can stop worrying about bad grades, poor communication skills, sketchy backgrounds, and reading online negatively affecting your job application.  The key is to identify a way to stand out and differentiate yourself from the pool of applicants.

But when unemployment is high, does it matter?  Unless you have specialized skills, how do you differentiate yourself?  At the end of the day, unless you know someone, an employer evaluates your application based on a cover letter and a resume.  When I review resumes, I rarely review anything more than the skills someone has.  In fact, most of the resume leg work is handled for me by HR.  The mere fact that I speak to you means you have an honest to god shot at the job.  But then, it comes entirely down to communication skills.  Can you do the job?  Can you communicate with your peers, subordinates and superiors?  If you can’t demonstrate those skills in a 30-60 minute interview, it doesn’t matter what capabilities you have on paper.  I don’t believe you can do the job.

Note, I’m considering the job you’re looking for is in product management so the lens I look at may be different than what Penelope was talking about.

Get the house in order, but don’t forget about your room too

[tweetmeme source=”sbindal” only_single=false]

Product guy: “Sales needs to put up some numbers on this new product.”

Sales gal: “Sales isn’t built to sell what you want them to sell the way you want them to sell it.”

Product guy: “That’s not my problem.  I’m going to keep pushing.”

Sound familiar?  How often have we built interesting products with really awesome cool features but no one buys them?  Why does that happen?

Lately, I’ve been in a similar situation, and I’m beginning to believe strongly that it comes down to execution.  The product is great.  It’s how we enable the rest of the organization to be successful in selling it.

Each department, from engineering to product management to support to marketing and sales, depends on each other in order to enable revenue generation across the business.  Product comes up with the market problems and helps define solutions with engineering.  Engineering builds solutions that product and marketing position with the sales team to sell to end customers.  Support and Services enable customers to succeed in solving their problems with the built solution.  One step can’t happen with the step before it and the overall goal of revenue generation wouldn’t occur unless each step in the overly simple flow above happens.

As a product manager, recognizing that interdependence is paramount.  But even more so, you need to deal with the interdependence and help each party succeed with their role to enable revenue generation.  Pushing on a team to deliver without enabling them will ultimately cause the revenue generation to break down.

So what does that mean?  You have to micromanage start to finish and make sure a solution to the problem spans the entire organization and makes it into the hands of a customer?

Yes and no.  No on the micromanaging, yes on making sure the solution works end to end.

A product manager has to follow through on the promise to solve market problems for customers.  If you’re not delivering to customers via your sales, support or services team, what value does the solution to the market problem hold?  Have you really solved the problem?  Have you eliminated a pain point?

I encourage all product oriented folks to consider not only how to build something, but also how to enable the organization to deliver the solution into customers hands.