Tag Archives: software product management

The Top 5 Rookie Mistakes in Software – #3 Techno Hype

technology.jpg

The Technology Dream

It’s just a tool, not a Strategy

It’s amazing how often technology gets confused and spun as a marketable feature. It’s not uncommon for companies and governments, for instance, to state that they will “Leverage Technology” as a business strategy. In the same breath, they’re also going to reduce unemployment, clean up the environment and fix the economy. Sure they will.

There’s an exciting appeal to ‘technology’.  There’s still a mystery and newness to even the word that elicits a dreamy promise of endless possibility.  It’s impressive apps like Google Earth, Halo 3 or the iPhone that people likely think of when talking about technology; apps that look good, sell well, and entice people to get lost and obsessed in them.

Sexy apps, however, are built by clever people with a focused vision around capability, content and a dreamy interface. The fact that they leverage technology is almost incidental. It’s easy to get caught up in the excitment of the dream and forget that business is still business regardless of the tool you use.  The truth is, it’s not uncommon for both business people and technical people to miss the point that technology is only a tool. Without a purpose, that tool is just a means to an undefined end.

Without establishing a direction and purpose for a software product that is focused on boring old things like: User, Market and your Business; your technology dream will simply deflate into another expensive mistake rather than a hot app.

The Framework Dilemma

As technology professionals, we get caught up in the dream too.  I’ve been guilty many times of approaching business problems with a technical solution without stepping back and wondering if it’s truly the right thing to do. It’s easy to get wrapped-up in the world you know and use that as the solution to all problems. “Have you considered building an Application Integration Framework?” – Those were my words. It seemed like a reasonable thing to suggest. This guy’s media company had multiple products that couldn’t talk to each other and ‘Integration’ was high on his agenda.

“NO! NO FRAMEWORKS!” – Was his response.  He even stood up out of his chair and leaned forward towards me pretty aggressively when he said it.

Wo, that guy was jaded. But I understand why now.  He quickly calmed himself and explained to me that a consulting company had sold him the same line a couple years ago. They spent those 2 years in, what I call, “a Dark Place”, just building a Framework. They didn’t consult with them about what the products do, or what the user needs, or business drivers, or the data or how this could tie into their overall technical strategy – nothing like that. They just built a framework.  It took 2 years of nothing tangible, but these consultants were finally kicked off the property. All there was to show for the $1.2 million spent was a bunch of code that had no business value.  I’m sure it was a brilliantly designed framework, but it didn’t do anything. I’m also sure there are thousands of skillfully composed frameworks out there sitting lonely on subversion servers around the world. I’ve personally participated in a framework or two that went nowhere. It’s a common thing for developers to want to do.

targeted.jpg

I don’t want to dismiss the importance of a proper architecture and framework; all software applications need a solid foundation. But they have to be built to fit the business need, and with a specific user-driven purpose.  Frameworks should be small, lightweight and grow with the product. Key to making sure that happens is: every aspect of a framework has to have a consumer. If someone on your team is building a component or framework or utility in anticipation of the potential of it being useful, that effort should be denied.

Technology For Technology Sake

My old boss used to have this tendency to wander into my office and recount stories about his past. He didn’t have all that much material, so his stories got repeated a fair bit – I didn’t have the heart to tell him that of course.  Anyway, one of his more riveting stories I got to know well, was about the specifics of a product idea of his that failed. It was essentially like this: a data service architecture that could connect to multiple databases; a domain layer that sat on top of that which reconciled data from these different locations; on top of that was a communication layer based on web services and finally there was a forms builder to create custom interfaces as the top layer of the product.  He thought it was such a great idea and would shake his head in bewilderment as to why it never went anywhere. “Well, what did it do?” I asked him one brave day. “It could connect to multiple databases.” Was his answer.

“To do what though?” I asked.

“Well, to do anything.” He said.

“Anything that needs multiple databases…” I said, to be agreeable; but really I just wanted to get out of the conversation.

So, who’s going to buy that? It’s a thing that doesn’t have any real purpose, except to say it serves a purpose behind an unknown purpose. A body without a head. I didn’t have the heart to tell him, of course, because he thought it was so awesome … and it was kind of his baby. But like a lot of people, he chose to build technology for technology sake, and didn’t appear to understand that that isn’t a product or strategy, it’s only a tool.

Chris Ronak

The Top 5 Rookie Mistakes in Software – #5

Lack of Focus

(read the intro first if you haven’t already)

Call it hubris, call it ego.  Call it a lack of understanding of the market and user, but a huge rookie mistake is to try to do too much.  How many times have you heard this bit of common-sense wisdom, “It doesn’t have to do a lot, just build it to do a few key things and do those things well.”?  It makes sense right?

It’s unfortunately easy to lose sight of this little rule-of-thumb when the momentum of product roadmap overtakes you.  You browse around a competitor’s website, for example, and discover that they’ve just released a new version that has a new feature X; but you have no plans to build feature X in your tool.  Well, now you need to add feature X to your scope to remain competitive.  Or, maybe your legacy product has feature Y and your existing customers have learned to depend on feature Y to do their business.  How can you ship your new product without feature Y? Add that to the scope.

Add a hundred more components and modules and exports and reports that keep getting added and added through demands from a few sales & marketing people, some customers, your favorite SME’s and a BA.  Your simple, focused product has now ballooned into a Colossus that will take 800 man-years to release.

So, am I talking about Scope Creep?

Not at all.  Scope Creep is one of those old, pre-Agile sayings that poorly organized dev shops used as an excuse not to ship software.

Scope will always change and creep.  It’s normal, healthy and all a part of building an effective product roadmap.  To maximize the competitive opportunity of your software, you need to be open to new market information, business drivers and innovative ideas.  These will always change and add to your product backlog (total scope).  Change, scope creep, uncertainty, etc. is all GOOD, wholesome stuff in the world of software and technology. Our learning path evolves every minute of the day.  Think of it this way: if you don’t know more in 6 months than you do right now, you’re not really doing your job.

I’m talking more about confidence.  Cojones.  The guts to ship early to a market you understand.

The true challenge is having the nerve to ship your software before the entire scope is complete.  As a rookie leader, you likely won’t understand that your software team can ship a quality product with the minimum possible feature set that will bring business value – even modest business value – even if it’s only to a percentage of the total market opportunity you’re shooting for.  You probably won’t think it can be accomplished as a continuous incremental improvement of features over a time period of x-months or years.  You’ll be more inclined to want everything – you’ll want the whole scope, first time, and ship that with a huge boom – you must, as a rookie, obliterate the competition with one crushing blow.  Or, maybe yours isn’t an ego issue. Maybe you’ll want everything because you’re not confident enough in your understanding of the market and users; so best hit them with everything and maybe something will stick.

Either way, Big Rookie Mistake.

Wanting everything is obviously the wrong way to think about it both from a technical and business point of view.  The fact is, it actually takes a great deal more courage to be laser-focused and put your product out to market with a simple, lightweight vision to accomplish a few targeted things to a clear and strategic market.  There is much more of a calculated mastery in that.

And, sure, you will continue to have a product backlog of great, innovative ideas to add to the product over time.  Believe me, there’s time for that.  What the more experienced Business Leader will know is that: getting your more precicely-focused product to market accomplishes four important things:

  1. You now have commercial adoption of your product. (Reduced risk)
  2. You’ve minimized the investment needed to generate revenues. Your product is now out there making money, and you’ve spent a fraction of what your total scope will cost. (Increased ROI)
  3. You are now receiving valuable customer feedback on your product, which will help you further prioritize the next features to add. (Strategic market information)
  4. You and your team have proven that you can build and ship successful software. (Time to celebrate

Prioritize

Ok, so now if you don’t want to fall into this trap, what do you do?  The key is to prioritize the backlog.  You have 100 innovative, killer features you want to put into the product, but you only have room for 10 this realease.  Someone has to take ownership of which 10, and in what priority.  Then prioritize the next 10, and so on.  Maybe the remaining 90 will change after you’ve shipped the first 10. That’s a good thing.  KeepThis is the Key prioritizing the next 10 (or however many you choose). Have a look at this article by Dennis Stevens on Capability Analysis for some good insight on prioritizing features.

Who owns that?  Typically your Product Manager or Product Owner. Maybe you do.  Whoever it is, remember, one of the most important things for a software development team to be armed with is: What To Do Next.  Mike Cohn has some sound ideas on the Product Owner, backlog and other gems to help gain more context with this.

Stay tuned for Rookie Mistake #4.

Chris Ronak

The Top 5 Rookie Mistakes In Software – Intro

Introduction

It’s pretty easy to throw some software together.  Almost anyone can do it.  Simple tools, Drag&Drop screen designers, sample databases, etc. make creating a software app just a few mouse clicks away.

I used to work with a sales guy whose family owned a sheep farm that he helped out with on occasion.  After getting a bit frustrated with how disorganized his family was about managing their sheep, he decided to do something about it.  So after reading a couple blogs, he bought a “For Dummies” book and taught himself VB.  He hooked it up to an Access database and in a few weekends he had built a sheep-tracking system.  Bam, just like that.  Easy.  Even a sales guy with a mere hint of technical aptitude can write software.

As it turns out, lots of non–technical people dive into the software game.   After all, how hard could it be?Small team of developers If you can’t do it yourself, you just hire some developers, tell them what to do, and they make it work.  Easy.

It’s interesting in a way, that there are so few barriers inhibiting inexperienced people from launching a software initiative.   In their mind, it’s just a few screens, buttons & graphics – it just doesn’t look that complicated.  Even if it’s a highly-integrated enterprise system that is connecting multiple disparate systems, performing complex business queries & algorithms and accessed by thousands of concurrent users – it’s still, at the end of the day, just a few screens & buttons.  Because that’s all they see.

The odd thing is, those same individuals wouldn’t dare dive into leading-up the design & construction of a 90-storey high-rise building without experience.   It’s clear why: a high-rise is more visual, physical and the obvious immensity of it is intimidating. They know you can’t just go hire a bunch of cement workers, plumbers & electricians to “Go build me a High-Rise!”  But somehow this happens all the time in software.   Curious, isn’t it?

So, to start a discussion around this pervasive problem, I thought I’d put together my Top 5 Rookie Mistakes that both inexperienced and experienced people make in software.  There are a lot more than 5, but I thought I’d try to stop there.

I have to caveat the perspective a bit.  There are many rookie mistakes made in an organization that don’t have a direct relation to the software/technology areas (marketing, sales, business development, finance, operations, etc.).  I’ll leave discussions around those to the experts.  I also refer a lot to product and market.  Regardless whether the software is to be delivered as an internal or commercial product, these rules are the same.

Learning to DanceAlso, there’s nothing wrong with being a rookie or the new guy.  The rookie is usually the person with the most energy and enthusiasm for an initiative; and is driven by a vision.  He/she isn’t jaded by mistakes & failure and can often become the true source of life for a project.  The intent here is to help to avoid common mistakes and pitfalls of that role; not to criticize the rookie.

So, here goes.  The Top 5 Rookie Mistakes in Software.  I’ll stagger them out over the next few days. This is, after all, an agile effort.

Chris Ronak

Nothing to see here, move along

NerdPassionsA few months ago I had lunch with a friend who wanted to pick my brain about some frustrations she was having with her company’s software development department.  Her company produces specialized machinery for something (actually, I forget what they do), but they also build and sell software products.  In her role, she leads up a marketing team in charge of commercialization, PR and marketing of their software.

She started the lunch in a quite civil mood – the food was great, the restaurant was awesome – but once she started talking about their software guys, she got a bit edgy.  “I don’t know what they’re doing.” She said, clearly agitated.  “We’re supposed to release this new version in 3 weeks, and I’ve never even seen it.  I don’t know what new features are actually going into it, and they won’t tell me.”

“Every Time I go to meet with them to get more information, they treat me like I’m an intruder – like I’m some annoying idiot from Marketing invading their turf.  All I get is hand-waving and the big brush-off: ‘Nothing to see here pretty lady…’ blah blah blah.”

“I don’t get it.  How am I supposed to do my job? We’re supposed to go live in 3 weeks and they won’t even show me!”

My immediate reactions while she was telling me this story were a bit like this:  I wanted to go strangle that software team.   It was clear that they were badly organized, lacked leadership, they’ll no doubt miss their release target, it will ship with a reduced set of features, and the quality will be poor.  I got especially annoyed when she went on to tell me that they were “Agile”.  Her comment was, “I know you do Agile too, but I don’t think it works.”  That was the clincher.

strangle

Agile is all about transparency, it’s about delivering continuous working software, it’s about inviting all stakeholders in to participate in the development of a product.  Like anything, there are a lot of pretenders out there using a popular concept to hide their own inability.

So, if you were in my shoes, in that situation, sitting across from her, what would you say she should do?

Should she escalate the issue to higher-ups?

Should she continue to badger them till she got answers?

Maybe she should just know-her place.   Bow down to the divine miracle-makers in software.  Wait patiently until they’ve completed the magic-of-software-development before asking more tedious marketing questions.

What would you say? (see poll below)

Ultimately, there are so many things wrong with this situation; I struggle to know where to begin.  So, I’ll make a quick list of the obvious problems that this represents before diving into any detail:

  1. There’s a clear misaligned idea of product ‘ownership’.  While the product should be owned by the business as a whole, the development team appears to view their role as somehow ‘more entitled’
  2. There is a dangerous breakdown in Transparency and Communication
  3. The software team doesn’t know how to ‘ship’ software

A misaligned idea of product ‘ownership’

Clearly many software teams are compelled to believe that what they do – their role in their organization – is to ‘write software’.  Which, in some respects, has some functional truth to it; but the greater truth to what technology professionals do is, “Build Market-Driven Products”.

So, okay, maybe that statement makes you want to roll your eyes to the sky … but at the end of the day, we all work for a company that is in the business of doing business.  Making money.  Whether you’re building commercial or internal software, your company is investing in your time because they believe that it will help them make money.  It’s pretty rare that someone will pay you to play with technology.  The fact is, they’re paying you to do whatever you can to produce a product that has the maximum market potential and ROI so that they can make money.

The long and short of all that is: the technology team doesn’t ‘own’ the product and they have no right to throw up barriers around that product when other stakeholders with equal ownership need to participate in the product’s success.  The product is owned by the business, and the software group’s contribution to that should be a business-driven contribution. NOT a technology-driven contribution.

A Breakdown in Transparency

Software developers have a strong desire to hide in a dark corner and fidget away at their work – their creation – for as long as they can get away with.  The goal is to reappear, unveil the masterpiece with a “Ta Da!” and crowds will applaud the genius, the angels will sing and he will have saved the day.

This is likely the most dangerous thing in the world of software.nothing to see here

Ensuring that your team is fully transparent from all aspects of communication, visibility and availability of working product is absolutely fundamental to a successful software project. If you’re getting pushed off with the “Move along, nothing to see here…” attitude from the dev shop, it’s a clear sign that things are not well in that department.

Learn to ShipSoftware

I just had a chat with my friend, and as it turns out, 4 months later, they still haven’t shipped that release.  And it’s still not clear to her, or anyone else outside the technology department, what will be released or when.

Writing the code is only one aspect of creating a commercial product that you deliver to happy customers (internal or commercial).  The act of shipping that software product is craft that requires practice, experience and a lot of planning.  It’s tricky to ship.  No question.  So, to manage the risk and pitfalls that exist around getting your product to market, best practices tell us to ship all the time.  Ship your software as often as you can. Even if it’s only to internal stakeholders – your BA, Product Manager, trusted clients, etc.  Ship.

If you are on the outside looking in; and your dev group can’t prove that they can ship the software asset you’re investing in long before the release date – this is another sign that things are not well in that department.

Chris Ronak