Loved this slide deck from HubSpot on SlideShare about terrible places to work.
Why, well at Citrix we are all about mobile work styles; the ability to work anytime, from anywhere, on any device it is a great message that everyone gets. But I have to admit, there are of course some practical limits to where you may actually want to work, and this deck hits the spot; roof top edges, snow top hills (in the wrong shoes) and do you really want to work on the beach! Look out for the retro reference to Wonder Woman's plane.
Monday 29 April 2013
Friday 26 April 2013
Seth's Blog: Skeuomorphs = failure
Seth's Blog: Skeuomorphs = failure
Great article on why we should abandon skeuomorphs because they hold back innovation and the user experience. If you are any doubt about this have a read of some great research which threatens to over throw the long standing qwerty keyboard with a new design for thumb powered smart phones and tablets.
Great article on why we should abandon skeuomorphs because they hold back innovation and the user experience. If you are any doubt about this have a read of some great research which threatens to over throw the long standing qwerty keyboard with a new design for thumb powered smart phones and tablets.
The "seed crystal" the way to personal growth and development
I would thoroughly recommend mixing things up - always worked in big company, try a startup. You will be surprised by what you learn about the job you do, and it will challenge your abilities. It may take time to adjust in either direction, and you may find you prefer it the way things were but at least you will know for sure.
Of course, you don't have to quit your job to do things differently! Spend some time analysing what you do; how you do it; what you need from your job (don't pick the easy option "I need a course"); most important of all look at what don't you do. There are a couple of great ways to benchmark your product management skills against your peers; review job adverts for your current role (or the one you are looking at fulfilling) alternatively use the Pragmatic Marketing Framework and their Annual Survey to perform a self appraisal.
All it takes is that seed to crystalise the way forward...
Not involved in win loss analysis, get involved, even if it is eaves dropping in on the calls.
Doing the occasional roadmap? Set yourself a target for the quarter, sales will soon start calling upon you when they realise the value you can add. I have done more roadmap presentations to customers in the last quarter, than I probably did in three years at Neverfail.
Blogging is pretty much part of product management these days, but I had never done it before I joined Citrix. Why? Because it was never expected of me. I had thought about it, but to be honest I was too maxed out to start trying something new, so I just left it to Marketing. That all changed when I joined Citrix, I don't suddenly have any more time in my new job, but Citrix expect me to blog about XenDesktop (especially in the run up to the launch of Excalibur). The important lesson, I have realised the benefits of it when it comes to promoting products.
Learning new skills, doing things differently is essential if we want to avoid the pitfalls that lay in wait if we become complacent. There is nothing worse than thinking we know all the answers - because no matter how experienced we become the answers always lie outside the company. If you aren't constantly thinking "what don't I know?", "why is this true?" are you really thinking about your customer, or your market problems in the right way.
--- Challenge yourself it is worth it.
Of course, you don't have to quit your job to do things differently! Spend some time analysing what you do; how you do it; what you need from your job (don't pick the easy option "I need a course"); most important of all look at what don't you do. There are a couple of great ways to benchmark your product management skills against your peers; review job adverts for your current role (or the one you are looking at fulfilling) alternatively use the Pragmatic Marketing Framework and their Annual Survey to perform a self appraisal.
All it takes is that seed to crystalise the way forward...
Not involved in win loss analysis, get involved, even if it is eaves dropping in on the calls.
Doing the occasional roadmap? Set yourself a target for the quarter, sales will soon start calling upon you when they realise the value you can add. I have done more roadmap presentations to customers in the last quarter, than I probably did in three years at Neverfail.
Blogging is pretty much part of product management these days, but I had never done it before I joined Citrix. Why? Because it was never expected of me. I had thought about it, but to be honest I was too maxed out to start trying something new, so I just left it to Marketing. That all changed when I joined Citrix, I don't suddenly have any more time in my new job, but Citrix expect me to blog about XenDesktop (especially in the run up to the launch of Excalibur). The important lesson, I have realised the benefits of it when it comes to promoting products.
Learning new skills, doing things differently is essential if we want to avoid the pitfalls that lay in wait if we become complacent. There is nothing worse than thinking we know all the answers - because no matter how experienced we become the answers always lie outside the company. If you aren't constantly thinking "what don't I know?", "why is this true?" are you really thinking about your customer, or your market problems in the right way.
--- Challenge yourself it is worth it.
Thursday 25 April 2013
Are you experienced? Time to get out of your comfort zone...
Before joining Citrix in June last year, I had spent over four years in product management when one day something dawned on me - my product management experience was limited to a single market need; unlike the experience accrued in development, test and support roles! Sure my experience at Neverfail had been broadened by working closely with OEM partners like VMware but this was still solving the same set of problems for customers.
What sparked this realisation? An opportunity to work at Citrix came up. Having never worked for a large software vendor it forced me to take stock of my decision to always work at startups. I enjoyed the startup vibe, there are always opportunities to do something different, and ultimately it proved to be an excellent inroad to product management.
Sure you can learn new skills, push yourself to do things differently wherever you work (in fact this is essential if you want your career to progress) but if you simply move between similar environments there is a danger you view problems through the same lens, fall into the same habits or work patterns. So I figured if I wanted to become an experienced product manager not only should I manage different products but I should do it in a different environment...
What sparked this realisation? An opportunity to work at Citrix came up. Having never worked for a large software vendor it forced me to take stock of my decision to always work at startups. I enjoyed the startup vibe, there are always opportunities to do something different, and ultimately it proved to be an excellent inroad to product management.
Sure you can learn new skills, push yourself to do things differently wherever you work (in fact this is essential if you want your career to progress) but if you simply move between similar environments there is a danger you view problems through the same lens, fall into the same habits or work patterns. So I figured if I wanted to become an experienced product manager not only should I manage different products but I should do it in a different environment...
Saturday 13 April 2013
Seth Godin article on public design
Some wise words on Seth's Blog about public design; the best designers understand what is important and what improves the experience it is not just about getting noticed
Disruptive products require prototypes
Marty Cagan's presentation 'Building Disruptive Products', @Mind the Product, covered the need for prototyping as the best way to validate an idea before it gets into production. He provided some sound guidelines on how to budget for them and to make sure the prototype did not go too far; they should cost no more than 20% of the development project, should provide no performance, require no testing, support limited platforms and should not deliver all the use cases or configuration options and finally remember it is disposable code. Tom recommended complementing the customer feedback on prototype testing with A/B testing as well.
I believe that we should include exploratory testing from a member of the test team too because this ultimately benefits the product. As Tom Chi pointed out, the purpose of prototyping is to learn everything you can about the 'problem space', developers learn about solving the problem. It is therefore equally important to learn about testability so you can design it in. Note the purpose of this adhoc testing is not to generate test plans, platform coverage or provide formal sign-off on the prototype. I have often heard concerns raised by members of test teams that they were not involved earlier enough in the project this has to change if we want to reduce the cost of product development; having spent 5+yrs in QA this is certainly something I can emphasize with.
So when we talk about putting prototypes in the hands of 'users' this should mean all the users in the product's life cycle both inside and out of the company; from the test team, Internal IT (hopefully you are eating your own dog food), SEs and Consultants and most importantly the customers. Word of warning, make sure you track who provided the feedback because external opinions must trump internal opinions - the best answers always come from outside the company. The Test Team are there to comment on testability, SEs and Consultants are there to comment on deployability (made up word alert) and to offer a view on how their customers use the product. When it comes to usability, the customer's opinion must trump all others.
I believe that we should include exploratory testing from a member of the test team too because this ultimately benefits the product. As Tom Chi pointed out, the purpose of prototyping is to learn everything you can about the 'problem space', developers learn about solving the problem. It is therefore equally important to learn about testability so you can design it in. Note the purpose of this adhoc testing is not to generate test plans, platform coverage or provide formal sign-off on the prototype. I have often heard concerns raised by members of test teams that they were not involved earlier enough in the project this has to change if we want to reduce the cost of product development; having spent 5+yrs in QA this is certainly something I can emphasize with.
So when we talk about putting prototypes in the hands of 'users' this should mean all the users in the product's life cycle both inside and out of the company; from the test team, Internal IT (hopefully you are eating your own dog food), SEs and Consultants and most importantly the customers. Word of warning, make sure you track who provided the feedback because external opinions must trump internal opinions - the best answers always come from outside the company. The Test Team are there to comment on testability, SEs and Consultants are there to comment on deployability (made up word alert) and to offer a view on how their customers use the product. When it comes to usability, the customer's opinion must trump all others.
Tuesday 9 April 2013
Lets Prototype...
During the presentation Tom Chi from Google stressed the
importance of minimising the time to try out your ideas so your team can work
at the speed of thought. This has two benefits, allows you to try out lots of ideas and reduces the emotional attachment to
the ideas themselves, making it easier it to let go of any failures. Compare
this to all the investment and emotion it takes to get software to a beta release when you can finally test out your ideas and uncover flawed assumptions - which you don't have time to resolve before you the committed release date!
Picking the right materials is important and probably easier for the physical prototype (paper, card, clay), but can be a little trickier for software. Check out this great interactive matrix of tools here, which can help you pick a suitable tool. I have seen simple animated white board drawings used effectively. Quick note on reuse - do not get caught up trying to reuse prototype code in the real product, and you should only reuse it between prototypes if it helps you produce prototypes faster. Don't fall into the trap of going deep either; otherwise you are at risk of building the end to end system.
Picking the right materials is important and probably easier for the physical prototype (paper, card, clay), but can be a little trickier for software. Check out this great interactive matrix of tools here, which can help you pick a suitable tool. I have seen simple animated white board drawings used effectively. Quick note on reuse - do not get caught up trying to reuse prototype code in the real product, and you should only reuse it between prototypes if it helps you produce prototypes faster. Don't fall into the trap of going deep either; otherwise you are at risk of building the end to end system.
Tom advocated giving
the prototype team rate based goals*. Why? It encourages producing many designs quickly which increases the chances of success. The probability
of finding the right solution increases as you try more ideas out – ‘suppose
your success rate is 5% of time and you try 20 things / ideas then the chance
of success is 64%, try 50 times then there is a 92% chance of success’. Trying
eliminates the guess work, ‘try don’t guess’ because ‘trying is not failing as
long as you are learning something, so look for what worked in each prototype
and then discard what didn’t’. The more you understand the problem space the better the product. When you don’t have hard data upon which to base your decisions, often the case when you are building new products, trying ideas out helps prevent
building HiPPO products.
*Rate based goals may seem contrary to creativity, however it should not deter you from using them - it is all about the number of ideas, good or bad it does not matter.
Subscribe to:
Posts (Atom)