At your level, people expect a good presentation — including the interview.
Effective presentation skills will not only help you sell your ideas and products, but it will elevate your personal brand. Management guru Peter Drucker once said, “As you move one step up from the bottom, your effectiveness depends on your ability to reach others through the spoken and written word.”
Apple CEO Steve Jobs is considered one of the best presenters in the corporate world today. In my previous article on his lecturing skills and my new book, The Presentation Secrets of Steve Jobs, I reveal the tactics behind his famed “reality distortion field,” outlining the exact techniques that Jobs uses to engage his audience.
Whether you’re a CEO, manager, consultant, entrepreneur, business owner, professional – or especially, a job seeker – Steve Jobs has something to teach you.
Here are five ways to sell yourself or your brand the Steve Jobs Way.
Sell dreams.
Steve Jobs doesn’t sell computers. He sells “tools to unleash your creativity.” You see, nobody cares about your job search (product ); they care about themselves, their problems and their dreams. Tell them how you can help them reach their dreams, and you’ll have won a customer (or fan) for life.
When Jobs introduced the iPod in 2001, he said that music transforms people’s lives and that in its own small way, Apple would be changing the world. Where most people saw an MP3 player, Jobs saw a better world.
How do you make the world a better place? How do you improve the lives of your customers? How will hiring you help a manager fulfill her dreams?
Don’t leave your listeners guessing.
Create Twitter-friendly headlines.
Steve Jobs has a one-sentence description — or vision — for every product he introduces.
- What’s the MacBook Air? “It’s the world’s thinnest notebook.”
- What’s an iPod? “It’s one thousand songs in your pocket.”
If you can’t explain yourself in 140 characters or fewer (a Twitter post), go back to the drawing board.
How would you describe the vision behind your personal brand? Long before I had Fortune 5 clients, I saw myself as “The communications coach for the world’s most admired brands.” In 61 characters, it gave my clients a reference point and gave me a vision to attain. Every product needs a vision — and so does every business professional.
Stick to the rule of three.
Most Steve Jobs presentations are divided into three parts. Neuroscientists are finding that humans think in “chunks” of three or four. Great presenters like Jobs don’t overload the brain with too many points. In media training, we coach executives to do the same: Stick to three main points they want to deliver in the course of an interview.
The same holds true for job interviews — stick to three main points that you want the recruiter to know about you and your experience.
- Introduce the three points early in the interview.
- Expand the points as the discussion unfolds.
- Summarize them at the end.
Strive for simplicity.
According to Steve Jobs, “Simplicity is the ultimate sophistication.” Not only are Apple’s products simple, so is the way the CEO articulates the vision behind those products. For example, Steve Jobs’ presentation slides are remarkably free from clutter.
Your resume should be as well.
Strive for simplicity in oral communications and in presentation design.
Practice like crazy.
Steve Jobs makes presentations look effortless because he works at it. He spends hours and hours over many, many weeks rehearsing every segment of his keynote presentations. Jobs takes nothing for granted, and neither should you. Practice presentations out loud. Practice for job interviews as well. Have a friend sit across from you and ask you tough questions. Rehearse your responses.
Better yet, record yourself and watch it back. It might a painful exercise but well worth it!
One more thing … Do what you love.
Career Advice from TheLadders
Steve Jobs revealed the secret to career success in a 2005 commencement address at Stanford University. He said, “Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven't found it yet, keep looking. Don't settle.” In this global economic crisis, many people are facing setbacks in their careers. Steve Jobs also faced setbacks but was convinced that the only thing which kept him going was the fact he had found his passion. Jobs once said his goal wasn’t to be the richest man in the cemetery ; it was going to bed at night thinking he had done something wonderful.
Do something wonderful, and you’ll know real career success and satisfaction. And that’s the kind of manager employers would die for.
Wednesday, October 21, 2009
Sell Yourself the Steve Jobs Way
Tuesday, October 06, 2009
Feed The Beast
This article is from Silicon Valley Product Group Newsletter - October 5, 2009.
Subscribe at: http://www.svpg.com Feed The Beast For those that haven't heard the term before, "feed the beast" refers to one
of the most common problems with product teams, and one of the top reasons
for failed projects. It's very easy to spot. If you find a product manager
that is scrambling to finish up his PRD because the developers are freeing
up from their current project on Monday and the very thought of the
developers not having a fresh spec ready to go sends the product manager
(and especially senior management) into a panic, that's what we call "feed
the beast." The beast is of course the development organization and the beast does have
a voracious appetite. Unfortunately, the beast generally can't distinguish
between something that's worth eating and something that's not. Beasts eat
PRD's and we all know what comes out the other end. This feed-the-beast mentality stems from the observation that the largest
cost in a product development organization is the engineers, so it's
important to keep them fully utilized. Ironically, this overly simplistic
view results in maximizing utilization (they are busy) but not maximizing
results (producing successful products). Further, this mindset tends to diminish the development organization's real
contribution. They are treated as a software factory optimized for coding
rather than a collaborative partner for discovering and delivering
successful products. I like to say that if you're using your developers for
only coding, you're only getting about half their value. Good product organizations understand that their responsibility is to
provide the development organization with something worth building;
something where they have evidence that the products that are created will
be successful. Part of this is simply management not understanding the difference between
building the right product, and building the product right. But often the
company's culture plays a role in creating this problem. I love what a great project manager can do to help you deliver quickly (see
www.svpg.com/ebays-secret-weapon/), but it's also true that in some
companies project management plays too central of a role, and the entire
focus becomes about schedule and resource utilization. This is why normally
I encourage project managers to take a back seat during product discovery,
and then move to the drivers seat only once you're sure you want to actually
build the product. I find this works well, except in situations where
there's nobody that knows how to drive in the drivers seat during discovery,
and I'm going to discuss this situation in the next article. So what do you do if you are stuck in this "just in time" situation? There
are several options: 1. the developers can work on critical infrastructure/headroom activities
(see www.svpg.com/engineering-wants-to-rewrite/) 2. the developers can work on fixing defects and improving performance 3. the developers can participate in product discovery activities In general, we try to build a backlog of useful product specs of about a
month or so. This way, if you run into trouble on a project (for example,
you test your idea on users and they think what you're proposing is a big
waste of time and they'd never use it), then you have work that is ready to
go while you move on to pursue other ideas. It is also possible that your project team is out of balance. If there are
too many developers relative to the number of product managers and
designers, then you will perpetually be behind and your organization is not
able to properly utilize the developers you have. I have seen some teams
where one product manager is trying to define products for 20 or more
developers and this is just a clear recipe for poor products. If you're not
sure about the proper ratios, see www.svpg.com/roles-and-ratios/. Just please remember that no matter what you do, your top priority is to
ensure that the team is building something worth building, and that the
development team is a very big investment for the company and should not be
wasted, either by having people waiting around or by rushing to build
something that will just have to be done over again later.
Subscribe at: http://www.svpg.com Feed The Beast For those that haven't heard the term before, "feed the beast" refers to one
of the most common problems with product teams, and one of the top reasons
for failed projects. It's very easy to spot. If you find a product manager
that is scrambling to finish up his PRD because the developers are freeing
up from their current project on Monday and the very thought of the
developers not having a fresh spec ready to go sends the product manager
(and especially senior management) into a panic, that's what we call "feed
the beast." The beast is of course the development organization and the beast does have
a voracious appetite. Unfortunately, the beast generally can't distinguish
between something that's worth eating and something that's not. Beasts eat
PRD's and we all know what comes out the other end. This feed-the-beast mentality stems from the observation that the largest
cost in a product development organization is the engineers, so it's
important to keep them fully utilized. Ironically, this overly simplistic
view results in maximizing utilization (they are busy) but not maximizing
results (producing successful products). Further, this mindset tends to diminish the development organization's real
contribution. They are treated as a software factory optimized for coding
rather than a collaborative partner for discovering and delivering
successful products. I like to say that if you're using your developers for
only coding, you're only getting about half their value. Good product organizations understand that their responsibility is to
provide the development organization with something worth building;
something where they have evidence that the products that are created will
be successful. Part of this is simply management not understanding the difference between
building the right product, and building the product right. But often the
company's culture plays a role in creating this problem. I love what a great project manager can do to help you deliver quickly (see
www.svpg.com/ebays-secret-weapon/), but it's also true that in some
companies project management plays too central of a role, and the entire
focus becomes about schedule and resource utilization. This is why normally
I encourage project managers to take a back seat during product discovery,
and then move to the drivers seat only once you're sure you want to actually
build the product. I find this works well, except in situations where
there's nobody that knows how to drive in the drivers seat during discovery,
and I'm going to discuss this situation in the next article. So what do you do if you are stuck in this "just in time" situation? There
are several options: 1. the developers can work on critical infrastructure/headroom activities
(see www.svpg.com/engineering-wants-to-rewrite/) 2. the developers can work on fixing defects and improving performance 3. the developers can participate in product discovery activities In general, we try to build a backlog of useful product specs of about a
month or so. This way, if you run into trouble on a project (for example,
you test your idea on users and they think what you're proposing is a big
waste of time and they'd never use it), then you have work that is ready to
go while you move on to pursue other ideas. It is also possible that your project team is out of balance. If there are
too many developers relative to the number of product managers and
designers, then you will perpetually be behind and your organization is not
able to properly utilize the developers you have. I have seen some teams
where one product manager is trying to define products for 20 or more
developers and this is just a clear recipe for poor products. If you're not
sure about the proper ratios, see www.svpg.com/roles-and-ratios/. Just please remember that no matter what you do, your top priority is to
ensure that the team is building something worth building, and that the
development team is a very big investment for the company and should not be
wasted, either by having people waiting around or by rushing to build
something that will just have to be done over again later.
Subscribe to:
Posts (Atom)
