Opinionated Product Development

January 11, 2013 Leave a comment

I was recently speaking with an entrepreneur about a failed software start-up, reflecting on lessons learned.

During our chat, I shared a thought that has crystalized over some years of experience: the idea that as a software company, you need to have a perspective on how the world works (or how it could work).  You could call this an opinion.

When your product has an opinion, it is capable of resonating with Clients, Users, and Partners.  If your product is opinionated, you may find that people drawn to the product because of the ideas and possibilities it inspires.

For example: at MindFire we’re trying to solve the challenge of how to do marketing automation in an increasingly multi-channel world, while maintaining our mission of helping marketers generate higher quality leads for their sales team.

We’re certainly not the only ones trying to solve this challenge. But we have a set of ideas, theories, and hypotheses embedded in our platform, which add up to give our software  a point of view — a way of seeing the world. (By the way, I believe these hypotheses are what you try to validate with a minimally viable product; read more about that here)

I think it is good to have opinionated product development. By that, I don’t mean that you should have a product development team of jerks and a-holes — but that there needs to be a strong sense of what drives the product and its values.  

Otherwise, it is easy to fall victim to development by committee, which is one of the things that seems to have led to problems for the entrepreneur I mentioned earlier.

What do you think?  Does the idea of opinionated product development make sense?  What are some of the dangers of opinionated development?

 

Filed under Product Mgmt Tagged with , , , ,

[Video] Daily Scrum Stand-up Meeting: A Real-Life Example

December 5, 2012 10 Comments

At MindFire, we’ve been using a daily stand-up meeting for our multi-channel marketing automation platform.  We’ve also applied it in other areas, including our Leadership Team, which does its stand-up at 11:00 AM.

Here’s how we run the engineering stand-up meeting:

1) We start promptly at 9:00 AM.  We experimented with having the meeting at 4:00 PM, but meeting towards the start of the day seemed to work better.  I personally enjoy the buzz from getting everyone together in the morning, hearing the prior day’s activities, and charting the day’s course.

As I walk into the meeting, I make it a point to greet everyone, shake hands (or a quick fist-bump), and look everyone in the eye and smile.  I don’t always succeed at this, but I like to try and give everyone a good start to the day.  I feel it makes a difference.

2) We time-box the meeting to 12 minutes.  We use an iPhone timer to keep us honest.  These days, we usually finish with about a minute to spare.  We used to get lazy and go for 20 or 30 minutes, but now that we stand up and use a timer, we’re good.  I check the timer from time-to-time during the meeting and sometimes call out the number of minutes remaining.  Even though each person only has a few minutes, you’ll notice that it doesn’t seemed rushed; everyone has plenty of time.

3) We go in the same order each day, cycling through 7 people.  The people involved are:

  • The Product Owner (me).  I report on both my product-related tasks, as well as whatever I’m working on with the Leadership Team or any other part of our company.  If someone listens carefully, they can get a pretty good sense for what’s going on elsewhere in the company.
  • Our QA lead, who also is involved with our Professional Services.  He goes first, and you’ll hear him mentioning working from home the prior day.  We do this from time-to-time to improve focus.
  • Our senior architect and 3 engineers, each of whom are responsible for a different sub-system.
  • A member of our Support Team, responsible for communicating Clients issues, escalated cases, and any other meaningful data (we use SalesForce.com to track all cases).  We added this person to our daily stand-up just recently, and we’ve already seen it pay dividends.

Even though we go in the same order each day (and it is written on the board!), I often forget.  Senior moment!

4) We stay fairly disciplined.  If something comes up during the meeting that requires additional discussion, we’re disciplined about putting it in the “parking lot” and discussing it later.  I have to resist asking a lot of questions; you’ll see me ask a few quick ones, but I try to keep us focused and moving forward.  If anyone is blocked, it’s my job to make sure that I do what I can to move them forward.  You’ll hear me ask about blocks after some of the updates.

5) We update the Sprint board.  We usually start updating User Story status (as a percentage towards completion) a few days into the Sprint, once we’ve started making progress.  We recently changed what we display on the board, and it seems to have made an improvement.  We can cover that in another post.

The meeting runs well if everyone is prepared (which is most often the case). Some come prepared with a summary of what they worked on, others seem to have great memories and can recite their work without notes. Personally, I write everything down in a Google Doc, and just reference this document during the meeting; otherwise, I’d never remember anything — maybe I’m getting old!

Here’s the video from one of our recent Scrum meetings; excuse the brief interruption around 1:45.  Enjoy!

Filed under Communication, Culture, Entrepreneurship, Leadership, Product Mgmt, Productivity Tagged with , , , ,

%d bloggers like this: