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

Lessons Learned Filing a Software Patent

January 10, 2013 1 Comment

Over the years, we’ve filed trademarks and copyrights (which are interesting in their own right), and now I’m having a great time working on some patents for various aspects of our product suite.

I’ll share some information that might be helpful if you find yourself in a similar situation: Read more of this post

Filed under Entrepreneurship, Product Mgmt, SAAS Tagged with , , , ,

Why Writing Product Specs Is A Waste Of Time

December 21, 2012 3 Comments

I’ve developed software in two distinct ways: (1) writing very detailed and elaborate specs, or (2) writing very little and instead using lots of pictures and conversations.

There are certainly situations where writing specs seems to make sense, but what I’ve found is that by and large, writing specs in an agile environment can be a complete waste of time.

(Note: There are situations where I’ve found it worth spending time writing things out; specifically, when the process of writing itself helps you clarify in your own mind what you’re trying to do.  I happen to be someone who gains clarity through the writing process — but expecting your engineers to read pages and pages of your precious thoughts is usually a waste of time.)

Here’s the process we’ve found to work; most of the time, we’re using some variation of these steps: Read more of this post

Filed under Product Mgmt, SAAS Tagged with , ,

SaaS Roadmap Planning in an Agile Environment

December 20, 2012 2 Comments

I’m often asked if there’s anything different about managing a roadmap in an agile environment. I don’t think so; since agile is (just) a methodology for delivering software, I don’t think having a roadmap and being agile are mutually exclusive. Let me know if you disagree.

Over the past few quarters, we’ve refined how we manage our marketing automation platform’s product roadmap (which we develop using agile methodologies).  As of today the platform has 525 Users, so the volume of feedback and demands is rapidly increasing.

Here are a few things we’ve found about managing a roadmap in this type of environment:

1. Creating a detailed roadmap for more than 1 quarter at a time seems to be a waste of effort. Read more of this post

Filed under Communication, Product Mgmt, SAAS Tagged with , ,

Tips For Running A Sprint Planning Meeting

December 15, 2012 2 Comments

Tips for running a Sprint Planning Meeting

Build better software, more quickly, with less risk

For the past 2 years or so, we’ve been using an Agile-ish methodology for the development of our marketing automation platform.

I’ve described how we use daily stand-ups (here’s a real-life video example) during development of our MVP (minimally viable product), and today I’ll share how we run our Sprint Planning Meetings.

Here are a few things about Sprint Planning that we’ve found to be uber-helpful: Read more of this post

Filed under Communication, Entrepreneurship, Leadership, Product Mgmt, SAAS Tagged with , , ,

Lessons Learned Developing a SAAS App

December 14, 2012 Leave a comment

In 2003 and 2004, as we were developing our cross-media LookWho’sClicking SaaS application, I had the privilege of developing our software in a way that has now become a part of my work-process: getting embedded at a Client’s location.

Early on during development, we succeeded at licensing our software for $4,500 to a local marketing services company (once we found our product/market fit, we eventually raised the price to $9,500).  The company was located about 20 miles from our office, and I started making frequent trips in order to do training and on-boarding. Since they were one of the first on our platform, there was a lot to learn (on both sides).

At noon each day, I’d drive to their office and help users with learning how to use our software.  In addition, I became very interested in how their business worked, and how our software made an impact on their clients, revenue, and margins.

Over the course of a few weeks, the practice of visiting their office became a daily occurrence, and eventually, I was able to grab an unused desk and set up shop.

Here’s what I found extremely helpful about getting embedded with a Client: Read more of this post

Filed under Entrepreneurship, Product Mgmt, SAAS Tagged with

Mind Hack: Increase Your Ability To Foresee The Future By 30%

December 7, 2012 2 Comments

I’m not a negative person, but here’s something I’ve noticed: projects fail at an alarming rate.  One reason seems to be that people are afraid to speak up during the planning phase.  Unless you’ve fostered a safe environment that encourages people to raise issues, concerns may fester in silence and only become evident when its too late.

A premortem is a technique (pioneered by a psychologist named Gary Klein) for minimizing this kind of risk.  Instead of being held after an event like a postmortem, the premortem is Read more of this post

Filed under Communication, Culture, Entrepreneurship, Leadership, Product Mgmt, Productivity, Strategy 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 , , , ,

6 Lessons Learned Creating a SaaS MVP (Minimally Viable Product)

November 28, 2012 5 Comments

Over the past few years, we’ve become big proponents of developing new products by creating an MVP: a minimally viable product.

An MVP is the smallest set of functionality required to meet the needs of your targeted User.

The goal of an MVP is to rapidly validate your product hypotheses. Every great product should have an opinion, a way of seeing the world. That view may (and should) evolve, but at some fundamental level, your product is based on some view of how something should work.

As a company, founder, or product owner, your goal is to get real feedback as early (and often) as possible to validate and refine your hypotheses. While it sounds easy, it can be difficult, especially learning to say no to things in order to remain “minimal”.

At MindFire, we’re 16 months past our MVP milestone for one of our products. While we’re still learning and iterating by gaining feedback from 400+ users, here’s a bit of what we’ve learned about developing an MVP:

  • The idea of an MVP may be hard for people accustomed to more traditional development methods to understand. You may find yourself working hard to remind your organization why everything isn’t perfect. The goal of an MVP is not perfection.
  • Creating a successful MVP requires that your engineers understand the User’s domain, their struggles, and the job they’re trying to do. In the absence of this understanding, it is very difficult to communicate an idea (or User Story). Without domain experience, you may find your team asking for detailed instructions. If this happens, you probably need to spend more time introducing your engineers to real Users.
  • The sooner your MVP is in the hands of real Users, the better off you are. Nothing counts until this happens. Customer feedback and usage is oxygen to your efforts.
  • You’ll have to work hard to resist over-engineering things. Don’t try to get things perfect. It’s better to acknowledge that its hard to predict the future, and thus, to instead get working software into the hands of users ASAP. The goal is not perfection; rather, you seek feedback on the question: do you have a product that provides value to your Users?
  • On the topic of feedback: be prepared for lots of it. If you’ve got a real MVP (one that although buggy, inherently works … at least most of the time), rest assured things will be missing. Users will ask for features, improvements, and sometimes flat-out tell you that something sucks. You may even hear “How on earth could you not have feature x?!?”  If you hear things like this, you’re on the right track. That’s oxygen!
  • A part of the MVP philosophy is an understanding that there is no one specific release point. In traditional methods, everyone works from detailed specs for months (or years!) towards a huge goal — often, in the end, falling short (been there, done that). In the MVP philosophy, you still have goals and milestones, but what’s more important is a deep respect for valuing fast iteration based on user feedback, rather than working towards monumental releases. What happens if you’re wrong when you get there? Much better to find out sooner.

Developing an MVP certainly hasn’t been easy, so perhaps in another post, I’ll share some of the things I’d do differently with an MVP the next time around. But what I can tell you from first-hand experience is that the benefits far exceed the difficulties.

What do you think of the idea of an MVP? In what situations is it best? If you’ve developed an MVP, what lessons have you learned?

Filed under Product Mgmt Tagged with , , , ,