Withings Wi-Fi Body Scale

http://www.withings.com/en/bodyscale

This is great. You use it just like a regular scale, but you can see your weight over a period of time from the apps they provide on the web, iPhone, or iPad. It also integrates with other services like RunKeeper. FitBit is coming out with a scale soon too but for now they are just taking pre-orders. I’ve been using this and I am very happy with it.

Withings Blood Pressure Monitor

http://www.withings.com/en/bloodpressuremonitor

Same idea as the Body Scale but for blood pressure. Personally I actually don’t care that much about my blood pressure. I have an old-school style pressure monitor and it’s been ideal for a while. Nothing to worry about. If it is something you care about this is what I’d want to get.

Basis

https://mybasis.com/

A sexy watch on steroids. It tracks your heart rate, activity, and calories burned.

I’ve been looking for something that tracks the calories burned. From my limited understanding there are really two techniques that can be used. The first is to measure the activity via an accelerometer. This is a common method used by cheaper devices like the fitbit and a number of watch-like gadgets. Another way of calculating is to measure moisture of your skin. The BodyBugg is the best known device for doing the latter; however, I’m not very attracted to it because it requires a paid subscription after the trial period is up and it is pretty damn big. This watch seems to be the most cutting edge. It uses two techniques for calculating calories burned, it comes in a small form factor.

Other than calories it measures your heart rate and activity. The activity is a good way to track sleep quality.

The bad part… it’s not yet available.

Last week I had coffee at Barista in the Pearl with Chris Miller (christopherdan), founder of Havoc Labs and EnsoCloud. Havoc Labs is a design agency building websites for a variety of customers. EnsoCloud is a CRM service, but calling it a CRM doesn’t do justice. EnsoCloud intrigues me because it has a unique approach to CRM. I think the service has great market potential and a great approach to building a product to address the customer needs.

“Behind every great website there is a great designer” – Chris Miller, Founder

What is EnsoCloud?

EnsoCloud is hosting service that enables agency and freelance designers to build and host dynamic websites for clients with the tools and languages designers know best without help from developers or operators.

How is EnsoCloud different from other CRM solutions?

While most CRM frameworks (e.g. Drupal, WP) are heavily focused on features sets as well as thick developer frameworks, EnsoCloud focuses exclusively on the user experience by enabling designers to build beautiful, highly functional, dynamic websites. I love this approach for two reasons.

First, the target audience is more finely tuned. Instead of having to deal with designers, operators, and developers to build a website, EnsoCloud enables just the designer to build websites. The designer just needs to define the HTML, CSS, and images, and then add markup to the HTML. Once uploaded to EnsoCloud this runs as a fully functional CRM system where the special tags can be used to add contents by the website owner (not designer) without having to worry about breaking the design.

Secondly, instead of building a complex feature rich technology, the project is scoped down and focuses on the key problem. This market in general is incredibly large. Many companies and services are focused on solving the same problem with technologies which are more burdensome than they are useful. Chris is going back to the root problem all the CRM systems have been trying to address for so long, but rethinking it from a different angle altogether: the designer.

What is the most important lesson learned so far?

Get the product out the door.

EnsoCloud re-launched in August. It was first targeted at small shops looking to create website. The service started at $5 per month. It also included a number of templates small businesses could use to build their websites. At first they were struggling making all the decisions about which features to include or punt. After launching the team realized that much of those discussions were irrelevant. They learned that some of their hypothesis were wrong:

The target audience was the small shops wanting an easy website. Turns out that this was a crowded business space. Also the resulting websites were always sub-par. At this point it became apparent that a designer is needed to have a good website.

The price point ($5/month) was way too low. First off, this price was too low for the company to be profitable. In the second iteration more options were given starting from $19/month. Turns out that when given numerous options most customers skipped the low-end prices and went right to the high-end prices. In other words, those that understood the value proposition were willing to pay the higher premiums.

What’s next?

“Nobody knows we exist”

The current set of customers are primarily agencies building websites for their own site or for other customers. It’s clear that they buy into the value proposition; however, there are still relatively few customers.

Continue iterating

From the first iteration of the product it was clear that assumptions were made, the product launched with those assumptions, some were right some were wrong, and then the product adjusted based on the data. This iterative model will continue to cycle to further hone the business model for the best product market fit. Some of the ideas I was proposing was to consider a Freemium model instead of a trial model.

Good Product Manager

Bad Product Manager

By Ben Horowitz and David Weiden

Note: this document focuses specifically on product management in the context of a “divlet” [small division] in AOL.  Related key assumptions are that there is a corresponding “business owner” in each of the brands, and that the “products” are generally online services intended for individuals.

A Good Product Manager plays critical role in a successful product.  A successful product is the highest impact contribution that anyone can make in the PD organization.  In fact, the number one criteria for selecting a Vice President is the candidate’s track record (or lack thereof) of successful products that become profitable businesses for their company.

Being a good product manager is so hard that most product managers at most companies fail to be good — and instead are bad.  Because product management is a highly leveraged position, a bad product manager leads to many other bad consequences, generally including the wrong product being built, which generally has a significant impact on revenue, morale, and reputation — of both the product manager and their company.

There are a number of straightforward principles that product managers can follow which will dramatically increase their chance of success.  Surprisingly, only very few product managers follow these principles.  Part of the problem is that these principles often are not articulated clearly, which this document attempts to address.

A final note is that product management is a demanding and high profile job.  Individuals should make sure they’re up to the challenge.

Summary points:

• CEO of the product
• Balance all important factors
• Clear, written communication with product development
• Clear goals and advantages
• Focus on the sales force and customers
• Other key skills
• Really good product manager

CEO of the product

• A good product manager acts like and is viewed as CEO of the product. CEOs drive vision and are ultimately responsible for their company’s success or failure.  The same is true with a good product manager in relation to their product.  Good product managers have a realistic vision of what success of their product means and they ensure that this vision becomes reality – whatever it takes.  Good product managers are viewed by the entire product team as the leader of the product.
• Bad product managers think of themselves as marketing resources. Bad product managers define their role narrowly as a marketing resource: someone who writes data sheets, arranges press releases, gets customer feedback, etc.  Bad product managers get all of their time sucked up by the various organizations they work with, they take product team minutes, they are gophers for engineering.
• Bad product managers have lots of excuses: not enough funding, the engineering manager is an idiot, Microsoft has 10 times as many engineers working on it, I’m overworked, I don’t get enough direction.  Once bad product managers fail, they point out that they predicted they would fail.  Barksdale doesn’t make these kinds of excuses and neither should the CEO of a product.

Good product managers balance all important factors

• Good PMs take all important factors into consideration. As CEO of the product, the product manager must understand and balance a wide variety of factors that affect product strategy and execution.
  • The primary factors to balance include:
    • Company goals & capabilities. Good product managers understand (or seek guidance on) overall company goals and set product strategy in that context.  Good product managers also understand the capabilities and limitations of their overall company.  For example, a good product manager knows if their company wants to maximize per deal revenues through a high-end direct salesforce to a few hundred customers OR if the company wants to maximize customers with an easy-to-use product for hundreds of thousands of customers through a diverse reseller channel.  A good product manager also knows  approximately how much and what kind of marketing resources the company will spend on these products.  Good product managers don’t always know the answer to these questions, but they know enough to ask when they don’t.
    • Customer demand
      • Good product managers listen to customers but they probe deeper into the underlying problems to get at the compelling value proposition for the customer.  If you had a noisy car you might ask for a louder stereo, but you would probably be a lot happier with a quieter car. A good product manager gets at that difference.  Good product managers also know what customers can & will pay for (sometimes that’s slightly different than what they want).
      • Good product managers do quantitative research.
      • Good product managers are certain that if they build a certain product, customers will buy it.  Good product managers understand that if they screw this up, they might as well pack it in so they go the extra mile to make sure they get this right.
    • Competition. Good product managers understand the architectural and business capabilities of the competition and know where the competitors can go easily and can’t go at all.  Good product managers know they must be better or different or they’re dead.  Note “different” can mean things other than product differences, like integration or distribution..
  • Know what you know and what you don’t know. A good product manager is acutely aware of what they know and why they know it, as well as what they don’t know.  A good product manager understands the difference between opinions, hunches, and objective facts.  A good product manager knows that their job is to fill in these gaps in knowledge, not to defend or obfuscate them.  A good product manager doesn’t ruin their credibility by over-stating their knowledge.  Note: Tim Howes contributed the word “obfuscate,” so don’t blame marketing for that.
  • Think ahead and monitor your assumptions.
    • Note all these factors need to be considered both now and over the lifetime of the product.  That is usually 1 – 2 years from now.
    • Good product managers also know what their important assumptions are and they monitor them from time to time to make sure they still hold.  For example, if a server product’s success assumed dominant client marketshare, the product plan should be re-evaluated as soon that assumption is threatened.
  • Good product managers will actively confirm their understanding with their managers and others on their team.
• Bad product managers miss the big picture or miss small but important factors. Bad product managers build a good product for a market their company isn’t in.  Bad product managers build a product that’s too complex for their company to sell.  Bad product managers build a product that will take too long to pay off.  Bad product managers ask customers leading questions and get biased answers. Bad product managers go on their instinct and “confirm” it with two unusual customers.  Bad product managers react only to the moves of their competitors and forget to develop their own product’s identity, letting it be just a hodge podge of what the competition is not doing.  Bad product managers aren’t savvy or confident enough to distinguish between interest and commitment to buy.  Bad product managers blindly listen to the loudest customers, and define a product that addresses yesterday’s needs of a handful of companies.  Bad product managers compare future products to today’s competition, or cite advantages customers don’t care about.  Bad product managers try to defend their lack of knowledge rather than gain the knowledge.  Bad product managers have blinders on and don’t notice when things change and notice only when their product fails.

Clear, written communication with product development

• Good product managers clearly define product requirements — in writing
  • One of the most important – if not the most important – job for a product manager is to define clearly and in as much detail as is necessary what the product should do, how fast it should be, etc.  Good product managers don’t forget to specify critical information.  Good product managers err on the side of clarity and are willing to explain the obvious to make sure it’s understood.  Good product managers also specify the whole product, including release criteria, platforms, etc., not only the new features.  Good product managers also sense and tackle hard issues – in writing – early in the development process.
  • Note a good product definition does not come down from a product manager in an ivory tower, but is based on research, information and a logical, transparent thought process that the entire team buys into.
    • Good product managers know that engineers are scientists by nature and value data much more than opinion.  Also, engineering and other parts of PD (QA, Doc, etc.) should be involved in that process.
    • Good product managers define a clear product vision and target that empowers engineering to fill in the details that are difficult to specify or anticipate.  As part of this, good product managers also explain why engineering should build a particular product a particular way.  A good product manager will not ask for a two ton collection of certain parts that will look a certain way and hope it comes out as a Porsche.
    • A good test of a product manager is for someone outside the product team to ask 5 different people in engineering, QA, and doc what their product is supposed to do and why and get the same answer.
    • Good product managers are respected by their engineering teams.  Engineering teams involve good product managers in difficult decisions.
  • Good product managers gather information from engineering informally and verbally, but good product managers give direction in writing to engineering..  Written communication to engineering is superior because it is more consistent across an entire product team, it is more lasting, it raises accountability.
  • Good product managers attend product team meetings regularly and make sure they’re around when engineering is making tradeoffs.
• Good product managers think their Product Requirements Document (PRD) is a big deal. The PRD is the single most important document the product manager maintains and in most cases should be the definitive source of direction from marketing to engineering (see Writing a Good PRD).
  • Good product managers keep PRDs up-to-date daily or weekly at a minimum.  Good product managers view the entire PRD process as a living ongoing process, because it is (engineering has new questions, market conditions change, etc.).  If anything changes in the PRD, a good product manager communicates the change clearly to the entire product team.
  • Good product managers don’t rest until they are sure that the product vision is consistent across product management, engineering, QA, tech pubs, and support and is reflected in the PRD.  They don’t rest, because they know that no great product ever emerged from a broad set of conflicting visions.
• Bad product managers cut corners on communication with engineering or misunderstand their role. Bad product managers specify the how not the what.  They want light and ask for a candle when their engineers could have built a light bulb.  Bad product managers have a bad feeling about an aspect of the product but leave it murky.  Bad product managers worry about specifying every feature in detail thinking they know more about how to solve a problem or how the product should behave or be architected.  Bad product managers put off hard decisions until the end of the product cycle.  Bad product managers write a PRD and assume engineering understands it.  Bad product managers don’t have time to update their PRD.  Bad product managers update the PRD and don’t tell anyone, or don’t tell enough people, or don’t explain why.  Bad PMs change engineering priorities based on the latest customer feedback or latest hot sales situation without going through the defined process.  Bad PMs ignore engineering requests or calls.

Clear goals and advantages

• Good product managers have clear goals. Good product managers are absolutely committed to success.  Good product managers define success as achieving explicit goals.  Goals that are important are written down.  Good product managers have written goals for their product and for their own personal objectives.
• Good product managers know the advantages of their product cold. Good product managers know how their product will be better / different than the competition.  This comprises a key part of the overall product vision from day one and is reflected in most things the product manager does.  Good product managers have these advantages written down and are consistent.
• Bad product managers. Bad product managers have mushy goals and mushy product advantages.  Bad product managers hesitate when asked for the advantages of their product.  Bad product managers have inconsistent product positioning and advantages change from time to time.

Focus on the sales force and customers

• Good product managers are loved by the salesforce. A good product manager will be known personally or by reputation by at least half the salesforce.  Good product managers know that salespeople have a choice of products to sell and, at a higher level, companies to work for, and selling a particular product manager’s product is optional.  Good product managers know that if the sales force doesn’t like their product, they will fail.  Good product managers know that to win over the sales force they have to be some combination of:
  • Focused on making them money — good product managers focus on and understand that salespeople are under a lot of pressure to make their quota, this quarter, and that’s about it.  Good product managers understand most salespeople care about things in that context and not much else, so they put things in that context without making the salesreps make a lot of intellectual leaps.  “Bell Atlantic paid $3m for directory because of abc feature” not “abc allows referential integrity to be maintained across entries.”
  • Knowledgeable of what actually happens in the field — nothing turns off a salesperson more than a product manager who rambles on about their product features and seems to have no idea of the salesperson’s actual situation.  Good product managers know if the salesperson understands what the product does or not (and if not they start with easy to understand basics), if customers do (if not they explain more why a customer would care than what the product does), etc.  Good product managers speak from experience.  “When I helped Bob close this deal…”
  • Around –  they’ve been out in the field, been to sales training, been to SE training, been to pitches, etc.
  • A good presenter
  • Responsive
  • Fun
• Good product managers know and understand customers. Good product managers know a handful of current and potential customers personally.  Good product managers understand the exact dynamics of real customer situations.  Good product managers leverage this knowledge with engineering, other customers, the salesforce, press and analysts, etc.
• Bad PMs don’t have time for the salesforce or customers. Bad product managers focus on their product and competitors and aren’t sure what’s going on in the field.  Bad product managers delegate working with sales.  Salespeople have either never heard of or dislike bad product managers.  Bad product managers are boring presenters.  Bad product managers talk about how future products will be great, but the current products are weak.  Bad product managers don’t care about individual customers.

Key skills

• Marketing & communication
  • Product management requires an understanding of and proficiency in though not deep expertise of a wide array of marketing functions.  For example, good product managers should be able to work effectively with PR and press and analysts, understand how to execute a product launch, develop collateral, staff a tradeshow, train the salesforce, etc.  (See Working with Press and Analysts.)
  • A core rule of good marketing is to have clearly articulated advantages that are consistent across materials (ideally from the PRD to customers to sales, etc.).  Related to this is the importance of creating leveragable collateral, FAQs, presentations, white papers.  In particular, a product manager should make sure a core set of updated collateral exists (annotated presentation, written positioning, primary silver bullets).  If your primary competitor is abc and the most recent competitive positioning on abs is nine months old and refers to the last release of their product, this is indicative of a bad product manager.  Also, good product managers take competition into account in developing their messages, but are not a slave to what the competition does.
• Time management and sense of what’s important
  • Good product managers focus their time in two areas: 1) tasks that are critical to their product success (e.g., export approval, mandatory licensing arrangements); 2) tasks that have a high impact on their business (closing big deals, updating their PRD, etc.).  Good product managers also leverage their time by completing FAQs, having a standard annotated presentation, doing good training, etc.
  • Bad product managers put out fires all day.  Bad product managers complain that they spend all day answering questions for the sales force and are swamped yet don’t create FAQs or other leveragable collateral.
• Discipline
  • A lot of product management is ad hoc.  Good product managers respect a base level of discipline and organization in their work.
    • Good product managers keep their project up-to-date in Signposts.
    • Good product managers send their status reports in on time every week, because they are disciplined.  Bad product managers forget to send in their status reports on time, because they don’t value discipline.
    • Good product managers don’t over-promise.  Good product managers keep developers doing product development. They don’t offer engineering resources for things that can and should be handled by sales or marketing.

Really good product manager

• Really good product managers demonstrate group product manager skills and capabilities while they are product managers.  (See Good Group Product Manager / Dead Group Product Manager.)  These skills include:
  • Be paranoid.  Really paranoid.
  • Work well with executives.
  • Leverage the entire organization.
  • Use whatever intensity is required to close critical issues.

I like learning about people. I like startups and I am heavily involved in one. I also enjoy coffee and an occasional drink. This blog is the fusion of these interests.

As a scrappy startup focusing on your core proposition you will cause some pain to your customers all while they still love the product. We’ve made a few of these mistakes, some big (leaving a security hole and getting hacked), some small (sending an annoying email to everyone). We don’t try to deny or hide any of it. In fact, the fundamental principle that runs through our veins is openness and accountability.

In cases where you owe your customers an apology, here is a formula that has worked for us.

(1) I’m sorry for…

First, you must confess that you screwed up. In the process you must take accountability and you must be open about the problem. This is critical; when you apologize you must identify what actually went wrong. It is critical because it is also a big opportunity to screw it up if you don’t do it right. For example, if by accident you send an annoying email to a customer (we did this once), you should say “We apologize for sending an annoying email”, the worst thing you could do would be to write “I’m sorry you felt annoyed by our email.”

(2) This is what went wrong…

Explain what went wrong. Again, there is a right way and a wrong way. This is where you can get your customers trust back. If you explain the issue to them in detail, they will feel respected that you confined in them and they will support your decisions. If you use this as an excuse you will not gain the customers trust as it will be clear that you are not taking accountability for your actions.

(3) This is what we are doing to fix this…

Lastly, you must make things right. At this point, you have better fixed the issue or have a clear plan of action. If you do not, this should be your number one priority. If you fixed the issue immediately, thats great, but don’t wait to have a fix ready before sending the apology. If you don’t have a fix ready, make a damn clear plan on how you will fix this. The plan is actually irrelevant, what you are actually doing here is making yourself accountable by telling your customers to make you accountable. You must deliver on your promises or you will lose your customers trust.

This formula works. What makes this work, isn’t the three pieces of data, but it is the common thread that runs through them: openness and accountability.

On PHP Fog I can create a new application, select a framework (e.g. WordPress, Drupal, CodeIgniter, etc), deploy it, setup SSH and git, pull the app, modify it, and redeploy in probably about 5 minutes. If someone already has SSH keys setup and git, that 5 minutes is about 1 minute.

I wanted to see what that experience is like trying to create a “Hello World” application on Windows Azure. So here I am documenting the steps, and my thoughts along the way.

I follow instructions I saw scattered, but provided by Microsoft. Unfortunately they suck at documentation: they write a lot but say very little and there is no single definitive guide.

Step 1: Install PHP

First of all, this is weird. I don’t plan on running my PHP app locally, so why should I setup PHP on this machine. I certainly don’t have to with PHP Fog.

Step 2: Instal PHP Again (and Azure SDK, tools, and Visual Studio)

Turns out I didn’t need to install PHP from the php website, instead, Microsoft provides a Web Platform Installer which installs PHP.

Step 3: Wait on installation

This seems to be taking a while.

Step 4: Set environment variables for PHP

Seems like this belongs in the installation, not as a separate step. Oh well. Here I’m just adding the PHP binaries to the path so I can use it on the command line.

Step 5: Install Azure PHP SDK

This doesn’t come with a nice installer. The PHP + Azure SDK requires that you download a zip, place it in a specific directory, and then I’ll have to set some variables. No installer here

Step 6: Set environment variables for SDK

Same screenshot again, this time to add the reference to the PHP Azure SDK binaries.

Step 7: Run scaffold to create a scaffold

My environment at this point is theoretically setup. I even ran the verification step to ensure it works. Now I need to create my application in the local environment. To create the application I need to run the scaffold tool.

Before I run the tool I am getting a bit frustrated. The simplest PHP application on mac can be created like this “echo ‘<?php echo “hello world”;?>’ > index.php“. But now I have to do a whole bunch of additional work to create the “scaffold” and later the “package”.  I hate having to create all this additional junk to define a package. And if I do, why can’t I just create a single file called config.ini or something.

Turns out this completely failed for me anyway. I got a bunch of errors. I dont’ know what’s up with this. Frankly, I’ve already spent a lot of time and I really don’t want to be diagnosing this.

Step 8: Configure you PHP File

This is ridiculous. I actually have to modify commented out code using a Microsoft syntax. WHY!? This is a terrible programming practice. This should be in a sperate configuration file, not in configuration. Blasphemy. I’m actually surprised by this, Microsoft actually has excellent coding practices and this inappropriate. Comments are human readable, code is for the machine.

Step 9: Plan B, downloading a sample

Since creating the sample app via the scaffolding tool failed, I went to plan B. I downloaded a sample from git-hub.

Step 10: Update my code

Finally! I am a developer and after 2 hours I finally got to coding. WOW!

Step 11: Run locally – Skip

I’m skipping this step because I don’t feel like running this locally, I am just trying to do the minimal work here to get the app onto Azure.

Step 12: Package

I was already frustrated with this concept of scaffolding which is introduced to me, a PHP developer, which is totally unrelated to PHP. Now I have to create a Package. I don’t want to learn this proprietary stuff to get an app running, but I just want to get the app into the cloud, so I’ll suck it up. I was scared that this wouldn’t work since the previous scaffolding command failed. But luckily it worked.

So now I have a package which is ready to be uploaded to Azure.

Step 13: Deploy

Yey, I’m ready to deploy. Just need to select the package and the configuration file (why I have two separate files confuses me.)

Step 14: Wait

This seems strange. I’m started writing this article while I was waiting. At some point I was starting to doubt it was going to deploy. It took something like 5+ minutes. That seems like a damn long time. On PHP Fog it takes us about 30 seconds to spin up new instances. After you have an instance it only takes seconds to deploy modifications.

Step 15: DONE!!!

http://phpfog.cloudapp.net/

Conclusion
I’ve built PHP Apps on PHP Fog, Cloud Control, Pagoda Box, AppFog, Cloud Foundry, Dot Cloud, Orchestra IO, and this is the worst experience for PHP developers by a LONG shot. Microsoft is actually pretty awesome when it comes to the developer experience for developers, as long as you stick to the full Microsoft stack (Visual Studio, Windows, Azure); if you go outside if it, you are in a world of pain.

I’m very tempted to write another article explaining what I think Microsoft would need to do to make Windows Azure attractive to open-source developers.

This is a great breakfast, despite making it for some random meal between lunch and dinner time.

It is a puff pastry filled with mushrooms, onions, peppers, and a whole egg, covered with a little bit of cheese, truffle salt and parsley (mostly decorative).

It’s relatively easy to make too…

Preheat the oven to 350 and take out the puff pastry to let it thaw (it usually comes frozen). I’ve never been bold enough to attempt making my own puff pastry. Keep it around in the freezer as it makes for great improve meals.

Saute the onions, mild peppers, and mushrooms (in that order, a minute or two apart). Bell peppers seem appropriate, but I used padron peppers instead, as that is all I had. I don’t know what quantities to use, as I totally eyeballed it. I’m sure you can come up with a variety of other great things to throw in there too if you don’t have those veggies. I bet bacon pieces would also be delicious. If using just veggies, add some S/P for flavor, or other herbs/spices.

Cut the puff pastry into big enough squares and just mold them out into the buttered-up muffin pan cups leaving room for the egg.

Scoop in the sauteed veggies into the cups. Crack open an egg, without breaking the yolk, and lightly pour it into the cup.

Lastly, (and optionally) sprinkle on some cheese and little bit of parsley. In my case I used Gouda cheese since that’s all I had, but I’m sure other sharp cheeses would work. I also sprinkled on some truffle salt. The veggies themselves I suspected would be fairly blend since I didn’t add much S/P or spices to it, so I figured the truffle would finish off the decoration.

This is one of the easiest and most delicious things I’ve made for breakfast. Here is what you do: (1) melt 2 tbl butter in a pie dish by placing it in the 400 degree oven, (2) mix 1 cup milk, 1 cup flour, and 6 eggs, (3) pour the mixture into the pie dish and bake for 20 minutes on 400. It’s that easy! I added a little twist to this classic recipe by adding sliced apples and sprinkled some cinnamon and sugar.

Despite not having any baking power/soda in it, the pancake rises quite a bit out of the pan in the heat. After taking it out, you can see it slowly deflating. It’s fun to watch.

Like I said, this is stupid easy to make. I think it’s one of my favorites given the little effort to put into it because it has such a nice egg texture and the flavor is great for adding sweet fruit (e.g. apples, peaches).

Microsoft is broken! I assume you agree with me, but if not, leave a comment or email me. Instead of talking about how it is broken, instead I’d like to look at ways that I would fix it. Based on my observations while working at Microsoft and at a startup (PHP Fog), I am making a number of recommendations Microsoft could implement. Starting from the bottom, the product team.

I am not an executive so I don’t know how to fix Microsoft from the top. I was never in any of the board room meetings or executive meetings so my guess is as good as yours. However, I was a Program Manager at Microsoft for 5.5 years working on components in Windows Server, Windows Client, the .NET Framework, and most recently Windows Azure AppFabric. The PM is one of three key roles working on product development at Microsoft, along with developers (who write code), and testers (who write code to test the developers code). Here is the list of things I would change, you will notice a few reoccurring themes.

1. Fire 90% of the Program Managers

Developers write code, testers verify. The Program Managers do everything else. The reality is that most of it is just intellectual masturbation; it rarely leads to direct contribution to the product. They are delegators and when they don’t have work to do, they create needless work for others. They seriously can spend 80%+ of their time in meetings and dragging others into them too.

2. Release weekly, not monthly or annually

Most products work on several year release cycles, and a lucky few work on several month release cycles. Whether the product is released on a longer schedule or not, the product teams should be releasing new functionality, even in small increments, every single week. Every release should be made visible to the fullest extent. Let people use it, play with it, break it, and provide feedback.

The benefits of this are endless. This will boost moral as there will be continuous gratification. The need for long term planning (“guessing”) will be alleviated and replaced with real customer feedback. Time will be saved from nasty planning and review meetings.

3. Get rid of NDAs

Saying anything publicly about plans is frowned upon at Microsoft. Keeping your mouth shut is justified by the fear of making promises to customers which can’t be delivered. This leads to an overall fear about saying anything about the product at all. It also makes it incredibly difficult to have a meaningful conversation with customers about product plans and getting their feedback on the product.

4. Fire all of the “Evangelists”.

There are a number of people at Microsoft that get the awesome job title like “technical evangelist”. These people get to present at conferences, they blog a ton, they do video demos, interviews, etc. They have it made. But they are not a part of the product team. The problem is that they are a layer between the customers and the product team. The product team built the product and they should get the glory of “evangelizing” it. But more importantly, the product team needs to have a dialog with customers and use these communication channels to hear what customers are saying directly. This is the perfect opportunity for the PMs. This is what they should be doing.

5. Say no to architects, specs, reviews, or approvals

I can’t even begin to explain how much time is spent by the product teams writing specifications, reviewing them, updating them, getting approvals from architects, peers, managers, etc. This phase of the development lifecycle takes up some %25-%50 of the time spent by the team. There are so many things wrong with this process: (1) customers are not involved in providing feedback, (2) the work is justified as a necessity for communication, yet they rarely get read after implementation starts (3) they are outdated the day the developer starts implementing them, (4) Time spent on writing specs is time not being spent on other far more important things.

6. More open community

The Program Managers, despite being “the voice of the customer”, actually get very little opportunities to talk to real customers. It’s shocking. Support is provided by some people in India, blogs are written sparsely, only the marketing department has access to the Twitter and Facebook page accounts for a given product, and there are only a few rare occasions where customers can get in touch with the product team. The product team should have control of the social media, they should be encouraged to write blogs, use the MSDN forums to the fullest extent, be on point to provide support, etc.  People at Microsoft will say “but anyone can go and do this”, the reality is that there are barriers to entry which just make it inconvenient.

7. Lower the bar for testing

The testers are often identified as the “quality gates”, the people that validate that the product does what it is supposed to do and that it does it fast and that it does it well. The problem is that the quality bar is so high that so much time is spent on ensuring that the product works the way it was “planned”; however, this also increases the time it takes to get the product into customers’ hands. The real testers are not the testers that work at Microsoft, the real testers are the customers. Once the customers validate that the product does what they wanted it to do, then the testers can start banging on the product to make it work well and make it work fast.

8. Fire the release managers

When you have a complicated schedule with weeks of pre-planning, planning, implementation, integration, stabilization, etc. you quickly need to hire a special type of program managers, who are called “release managers” at Microsoft. They are responsible for the schedule, pretty much like a Project Manager elsewhere. If some of the earlier recommendations are implemented, like a more frequent release schedule, lower testing bar, no review process, the need for the release manager will also be diminished (though not necessarily completely eliminated).

9. Refocus the PM role

Now I’ve fired 90% of the PMs, I’ve fired the release managers, architects and evangelists. This creates a gap which is prime for the PM. The Program Manager shouldn’t just “speak the voice of the customer”, instead, they should be fostering a relationship between the customer and the product. They should be providing support, blogging, presenting at conferences, tweeting, talking to customers with whatever channel available. They manage the team to make sure they ship small functional bits often and getting them into customers hands for testing.

Conclusion

There are two themes: go lean, and listen to your customers.

Based on these recommendations many people would be on the chopping block. In fact, some of the best people I worked with would be fired based on this criteria. I’m no exception. In retrospect, had I been my own manager at Microsoft I would have seriously considered firing myself.

Pitching Hacks

This book comes as a recommendation in order to understand traction. Establishing traction, regardless of the form, should be the highest priority for starting a company. Without traction, a company is just a few signed pieces of paper and wasted time in developing a product. Once you think about how to show traction for your business, you will quickly realize your priorities and that much of what you that was needed (developers, an office, etc) is completely unnecessary.

The Entrepreneur’s Guide to Customer Development for Tech Startups

The fact that this is called a “guide” is spot-on. This book is like cliff-notes to The Four Steps to an Epiphany, which establishes the rigorous customer development methodology. This really does read like a step-by-step guide for building the minimum viable product.

ReWork

This is written from the founders of 37signals.com. I highly recommend this book for all software development teams, not just entrepreneurs. While the other two books help you understand your business and get it off the ground, soon you will need to get into a rhythm of execution. This will help you understand how execute building a product (priorities, choosing what to build and not build, deciding when to hire, working hours, etc).