In my last article I discussed the keys to product optimization including A/B testing. However, I emphasized that this type of A/B testing is not the same as the A/B testing we do during product discovery. In this article I’d like to talk more about how we utilize live-data prototypes and A/B testing to facilitate product discovery.
Product Optimization is a hot topic. It can provide real value to teams. However, many people confuse optimization with product discovery. I’ve written about this earlier. Eric Ries of the Lean Startup movement also recently tried to clear up this confusion.
While mostly I focus on the techniques and best practices for creating great products, I have truly come to appreciate just how important culture is in contributing to great products. By culture I am including both company culture as well as the cultures of the people working at the company.
I recently asked the founder of a startup what he most wanted to know about marketing. He said, “What’s the best way to get publicity without feeling spammy?”
In this article I wanted to try to make the case that as an industry we need to expand the focus of User Experience well beyond usability.
Most of you hopefully already know that User Experience is much more than usability. But even those of you that do may be inadvertently hurting your case.
Readers of my book and articles know how much I value a strong project manager. I’ve written earlier about the positive impact to velocity a great project manager can have (see http://www.svpg.com/ebay_secret_weapon/ and http://www.svpg.com/product-management-vs-project-management/. And one of the reasons I advocate for Scrum is that as a process it values this role of project manager as “impediment remover” (known as the Scrum Master role).
In the consumer packaged goods industry, most people have a pretty clear image in mind when you refer to the “product” that they manage or work on. You can hold the bar of soap or the razor in your hand. However, in the Internet world, when we refer to “product” it is much less clear. First of all, most of the time we’re not even referring to a physical item but rather to software. Second, most of the time the software isn’t even installed on your computer but rather it’s running on a some remote server, or even more abstract, it’s running “in the cloud.”
I’m not the first person to come to this conclusion, but over the years, I’ve really come to dislike the entire concept of a “requirement.”
Believe it or not, there are still people out there that think that a technology company is really about two types of people: engineers and sales people. People to write the software, and people to go sell it. Everyone else is overhead and at best a necessary evil.