Monday 29 April 2013

Extreme Mobile Workstyles!

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.

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.

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.

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...

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.
 


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.
 
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.

Sunday 7 April 2013

Why Prototype

Tom Chi worked on the Google Glass project, he set the scene in the session at Mind the Product by talking about the pitfalls that befell the virtual reality headsets of the 90s. You simply could not wear the devices for any length of time, besides being bulky the weight was all distributed on the front of the face. Fifteen years on you could say, 'we can make them smaller and lighter today' but that betrays the discovery Tom and the team made with their prototype, which included the equivalent weight in components, electronics still have a finite weight which makes your nose ache! It was the rapid prototyping that taught the team to put the electronics behind the ear which mean that the ear could act like a fulcrum and lift the weight off the nose! If they had learnt that in the 90s, the larger components would not have been a problem.

Having come from a manufacturing engineering background myself, and spent many hours building prototypes out of all types of materials what he said about the benefits of prototyping resonated with me (how cool is 3D printing). You cannot justify tooling up a factory to build a product if you haven't prototyped it, proved it works and more importantly shown you can build it. The process of prototyping helps you uncover how it should be manufactured. In the world of software engineering prototyping is often frowned upon or simply overlooked because it is all bits and bytes which appear to be 'free'. You will hear teams say 'oh we'll just rewrite it', 'tweak it to work', 'it will take too much time to build, we may as well build the real thing', 'something for version x'. We'll explore why the time to build statement is flawed in the next blog post. But the costs of getting it wrong in software can be just as high; the launch fails, it does not do what they need, the product is too complicated, it is not performant, it lacks some core functionality or customers try and use it differently. Why wait until release day to find out what you have built the wrong thing, why spend more time building in complexity to handle ambiguity when a simpler product actually meets the needs of the customer.

The objective of prototyping is to learn what works and what doesn’t, for software this can be what types of interaction works, what questions you ask when interacting with the user, understanding how they use it, what short cuts they take and most importantly do they love it. The prototype can stop you going too far with an idea only to find out customers can’t or won’t use it. If you understand how people want to use the product it stops you projecting how you think it should be used on the customer and shows you what options and functionality are really important. The result you can build a far more elegant solution, with a far simpler data model at the back end. Why? The complexity that normally gets built in with the ‘what ifs’, ‘we may need this’, ‘but what if they want to do’ has eliminated. Simpler data models are more efficient, require less computation the result a faster leaner product that may even be brought to market sooner.

Getting it started, the prototype blog


Thanks to @Thirsty_Crow who pursued me to start my own blog over a few beers. So I have picked the template, fonts and widgets for my blogspot and now I need to write the first entry. Now the tricky bit, what to write in that first blog entry. I wanted it to be something memorable and it just so happened I came across my notes from the last years Mind The Product Conference where I had the good fortune to see Marty Cagan from SVProducts talk about building disruptive products and Tom Chi from Google present on prototyping. Both excellent speakers, with great ideas. So I thought I would kick off with prototyping because that is where I need to start with my first blog, I need to get something out there and see what works…