|
|
Blog Articles
Viewing entries tagged with 'product development process'
No Silver Bullet
More than 20 years ago Fred Brooks published a seminal essay on the nature of software, called “No Silver Bullet: Essence and Accidents of Software Engineering”. If you’ve never read it I’d highly encourage it, as even though it’s ancient by the standards of our industry, it’s still amazingly relevant and gets to the heart of why creating great software is so hard.
How To Kill Innovation
Last week I ran into two different software technology companies (neither in Silicon Valley) that had just recently brought in Six Sigma consultants. This caught me by surprise because it¹s been a very long time since I heard of a technology company even considering this. I'm hoping this was an anomaly, but in the spirit of "those who cannot remember the past are condemned to repeat it," I thought it's important to discuss quality-centric methodologies like Six Sigma.
Product Discovery Diary
When product managers and designers move from the very linear, Waterfall-based processes, to the much more iterative and exploratory discovery-based process that I and others advocate, they sometimes take a little while to appreciate and adapt to the fast pace and rhythm of product discovery.
Left Of The Line
I picked up this phrase “left of the line” from my friends at the e-commerce site kbb.com. At the highest level, creating software products involves figuring out what to build, and then building it. This line distinguishes those two fundamental activities. Note that this line exists whether you use conventional product development processes or an Agile/Scrum process, although the nature of the line is different.
The Origins of Agile
If your engineering team hasn’t already moved to some form of Agile methods (like Scrum or XP), then it’s likely they’re at least considering it. Agile really does attack some key problems that have plagued software teams for decades. But many product managers and designers, and to a lesser extent QA staff, are initially confused by Agile, unsure of their role in these methods. To be clear, these methods absolutely require these roles, but I attribute the confusion to the origin of Agile methods, and I’ve found that when I explain the origins, it helps to illuminate the problems that Agile was designed to solve, and what challenges remain.
The Product Council
Even in small companies, getting decisions made is often time-consuming and frustrating. Every product company needs a mechanism to get the key stakeholders and decision makers together to make timely and informed product decisions.
Lessons from Apple
I have to admit to a strong bias up front: I love Apple. I think they’re responsible for some of the best technology products our industry has produced in the past 25 years, and I have been a fan of the company since the Lisa (which I consider a prototype for the Mac). I view Steve Jobs as one of the best product managers of all time.
Gentle Deployment
One of the fun things about working on a 1.0 product is that you get to start fresh with your community of users. It’s true that your user base is still influenced by other products and services that they’ve been exposed to, but overall you don’t have to worry much about things like backwards compatibility or retraining your users. However, for most of us, we’re in the business of creating updates or new versions of existing products or services.
Rapid Response
I’ve talked elsewhere about the pitfalls of confusing product launch with success, and how important it is to not lose focus after you ship your product or service. In this article I wanted to say a little more about what you should be doing during this critical phase of your project.