Getting Lost Sucks
I went to pickup my wife, Rachel at the airport this evening. Man, does that place suck. OK, it’s easy to get to. And yes, it’s easy to find the terminal where you are heading. But, the parking. Ugh.
They have about 1 million parking garages. They are all labeled the same, and all are within a 1 block / 2 block radius of each other. Now, I’m not known for my directional prowess, but this place is more confusing than a labyrinth.
P2a? P2? P2b? Now, when you have a tired passenger lugging bags around and just wanted to go home to bed, it’s not fun to break out into a cold sweat and say, “oh shit. I’ve lost the car.” Oops. Luckily, Rachel is very forgiving person, otherwise, I probably would still be at LAX, trying to find my own way home.
Anyway, much to my chagrin, they have the same level within each garage that I parked in — 2b. Making it near impossible to say, “OK, I know I’m in 2b - where is that?” It’s freaking everywhere.
I’m making the trek back out there this week to pick-up a friend who is coming in for a few days to hang out. Needless to say I will be either a) taking Rachel with me as she actually has a sense of direction and location or b) - wait. There is no option b. I’m just hoping Rachel comes with me…otherwise, I’ll have a repeat of the same dilemma I created for us tonight.
hmmm. Weekend’s over. Must get some rest - long week coming down the pipe.
Managing by Milestone
I wanted to let everyone (well…all 1 or 2 of you) in on a little secret a learned recently: there are two ways in which you can be accountable.
You can be accountable for work, or you can be accountable for communication. And yes, there is a pretty big difference.
Now, of course, in the fast-paced “hectic” start-up world where everyone has to be good enough to a) wear multiple hats and b) want to contribute and wear multiple hats and be excited, there are many (if not all) the folks in the company that are both accountable for some work, and some communication. However, I just wanted to post about this because what else are blogs for if not to ramble on until you get something in your own mind?
So, what to do with this revelation. Well, being a product-centric/happy guy, I float towards wanting to be accountable for communication on projects that are not directly product related. This means I favor a setup where you manage by milestone and not detail. Why is that? To me, it’s a boatload more effective to sit down for 30 minutes each week with a team lead, go over key milestones identified at the outset of the project and log the issues as opposed to sitting down for 1+ hours with everyone on the entire team and going through the plan point-by-point.
Why do I care what Suzy is doing on Tuesday of next week? If you do, you might be slipping into a trap of micro-management.
Now, of course, anything I say should be taken with a grain of salt. I know nothing from nothing and am simply a geeky pleeb trying to work all this out and how it can work the best in the scenario I’m currently in.
With that being said, development project management has to be done differently in a small environment in order to work. It HAS to be agile. I’m 100% - no, 1,000% - convinced of this. There is NO other way to go.
My first step? Tearing up any spreadsheet that I had related to tracking dev schedules. What goes in its place? I’m pulling out some flip charts and writing the following:
Product Name - Release Number / Date / Sundial Location / Whatever
- What’s in the backlog?
- What’s been planned?
- What’s in development?
- What’s ready to ship?
I then track the overall status of the release itself. Smiley face / sad face, thumbs up thumbs down, whatever. It needs to be clear, it needs to be somewhat interactive, and developers have to be able to walk over to this thing and scratch their names off, or move a sticky note with a requirement on it to the next grouping (for example, development to ship / qa, whatever) when it’s ready to go.
People love to check their own names / tasks off of lists. I love to see people checking their own names and tasks they have ownership of off lists.
So, let’s throw another kooky wrench into the mix? What if you want everyone to see this schedule so they know what is being worked on when it comes to the life blood of the company (i.e., the products themselves). Well, that’s easy if everyone is ass in seat, in the office. However, that’s not always the case.
I’m thinking a Web cam.
Will this invade privacy? That’s the initial concern. How can you avoid that? Get 1 camera, point it at the dev schedule that’s on a wall in a grid taped together or on flip chart paper taped to the wall.
Oh wow — didn’t I just recommend to violate a cardinal rule of product management? Never, ever give sales specific dates / info on the dev schedule! Blasphemy!
Ehhhh…I’m starting to think it’s not going to matter so much — especially now that I’m dealing in more of a consumer-based mindset. Which, I’m loving by the way (whole other blog post on that bad boy topic).
I doubt any of that made sense. Which is fine. It’s working for me, and in my head it all makes sense. The litmus test will be to see if it makes sense for everyone else that it needs to make sense for. And if I can keep it clear enough in my head that when I start to tape big pieces of flip chart paper to the wall behind my desk.
God, I love my job.
Competitors Are Not Your Customers
One of the “standard” pieces of market data that I’ve always read about is competitive analysis. I’ve always been of the mind that successful products are built based on feedback and communication with who the actual users are.
There are some great articles on this topic already, so I don’t feel like I have to write all that much. However, this does tie back to my earlier post regarding the “party of four.” I do not include any competitive data within this for the simple reason that competitors are not your customers.
Who gives a crap if a competitor thinks you have a good product? Clearly, if you have built one that’s taking what they are doing into account, they will. They’ve put a lot of hard work into making sure their products are selling well and performing for their user base.
In that same token, I assume if a company has been identified as a competitor to a product or service, the competition, in essence, is for user base. At the end of the day, whoever is listening to the market / users / customers better will win.
To me, the trick is making sure you have the channels of communication with your users open, and you are in fact hearing what’s being said. It’s a two-pronged effect:
- If you have the channels open, but don’t listen, you lose
- If you want to listen, but don’t have the channels open, you won’t hear anything
Make sure that your channels for listening feed directly into how you feel your market will want to communicate with you, and will communicate the most effectively. Whether this is an e-mail form, telephone line, fax, whatever — make sure you are listening and hearing what the people who are paying you to use your product have to say.
Judging a Song by Its Cover
I was at the Virgin Megastore this evening in Hollywood with my lovely wife. She purchased some new records, and was gracious enough to pick me up a copy of The Long Halloween. Yes, I’m a geek…but I digress.
As we were getting back in to our car after our walk (it was a freaking long walk) I picked out one of the records she bought and put it in to listen to on our way home. I asked her about the band, and where she had heard of them before — to which she replied that she hadn’t.
I had to ask, “how did you know it would be a good record?” She told me that she didn’t, and simply picked it up because she liked the look of it, and thought it would suit her style of music.
Turns out, it did. I think she’s amazing — being able to tell that a band will suit her style of listening by looking at cover art. I can’t even tell you where I am when I get 3 blocks away from our apartment…
I guess marketing can make sales superfluous after all.
The Party of Four
The way that I see it, in a start-up, the most important thing are the products. Of course, I’m slightly biased.
Yes, you need to have a “grander” vision. A good handle on the broader scope of things and the bigger picture.
However, I like to think of each product as it’s own mini-business. When constructing and shaping the idea of one, you need to toss out the idea of the business vision, and work solely on the product vision. Of course, trust that the idea or innovation fits into the bigger scheme of things first. If it doesn’t maybe the idea has to be refined or tossed.
OK, ok. So say you’re past all that. What next? This leads to the title of the post — there are four things that I’ve found are a great way to get started on the foundations of the product itself.
I’ll walk through each of the four.
Problem?
Straight-up. What is the problem the product is trying to solve? If this can’t be defined, maybe the product idea needs to be revisited before proceeding.
Vision
What is the grander scheme of the product? A vision is 100% critical because it gives you perspective moving forward. Competitive decisions, feature choices, even priorities. All these choices can be a direct reflection of the vision. Is there something that can’t be decided? Go back to the vision. Does it fit the vision?
If not, chuck it. It it does, get it in there.
Market Segments
So what’s the other really important thing before writing a stitch of code? Deciding who the hell the code is being written for. If that’s not known, then how can features and priorities be decided upon?
I’ve found that there is a key difference here when building consumer products to business products. The segments for a business product can be a lot more broad as opposed to consumer, which tend to need to be more specific. Why is this? I think it’s because with consumer markets you’re dealing a TON more users that need to be pleased, in most cases.
I don’t believe this is hard & fast, but just lessons learned thus far.
User Goals
So once the market segments are decided upon, the goals the segments are worked toward when using the product need to be identified, so they can actually be reached.
I don’t think any of these can be ignored. They must be kept in front of everyone building and running toward the finish line together. One-page with bullet points outlining these things that are going to make the product a success. I think I’ll have more to write on this, but it has been a long week…
