Skip to content

  1. Change your scope

    In 1989, Caroline Paul became one of only a handful of women ever to become a San Francisco firefighter. Paul set out on an undercover mission to uncover sexism in the department. Her goal was to change the world by broadly exposing injustice through a documentary.

    However, Paul passed the entry exam and found no evidence if discrimination in the process. She decided to put aside her Stanford education and the expectations of her parents to pursue the adventures of public service.

    She spent 13 years in the San Francisco Fire Department, and touched untold number of lives during her tenure.

    You see, Caroline Paul wanted to make an impact, but her scope was wrong. Instead of broadly exposing injustices and driving for macro-level change, she made a direct impact on the lives of individuals at perhaps the most vulnerable moments of their lives; delivering babies, administering CPR, responding to gunshot wounds.

    I have not read it, but Paul chronicles her time spent in the San Francisco FD in her memoir, Fighting Fire (affiliate link).

    Categories: Personal, Stuff I Like.

  2. iPad Mini

    I have an iPad 2 which I stood in line at the Apple store to purchase the day it launched. I loved my iPad, but it was a pain to use when reading or watching video in bed, mostly because of the weight.

    So my wife got me a Mini for my birthday which has essentially the same hardware specs as the iPad 2 – same resolution (1024 x 768, not retina), memory (512Mb), processor (A5), but just a fraction of the weight. Of course the display is only 7.9″ as opposed to the larger iPad display, but my eyes are okay with it so far.

    If I hold the Mini in portrait orientation I can thumb type very effectively. I never did use the split keyboard much on the iPad 2, never could get a good feel for it as it’s not as if I was typing on a true split keyboard where my fingers rest on the home keys. On this point, my Android-using friends (I’m looking at you, @jspad) remind me that they don’t need to type with two hands because they use Swype. Touche.

    I tried to take notes on the mini in a business meeting where lots of note-taking was warranted. It was not a good experience. If you need to generate a lot of content, this is not the device for you. Although, neither is the iPad 1, 2, 3 or 4, however, I acknowledge that using an external keyboard made this easier for me on the 2 and would probably help out with the Mini. For those scenarios I’ll just stick with my MacBook (or whatever laptop I’m using) from now on.

    Overall, I love my new Mini because of its compactness and comparability in power to the iPad 2.

    Categories: Stuff I Like.

  3. Intrapreneurship: A discussion with Ash Maurya

    Last week we had the opportunity to meet with Ash Maurya, author of Running Lean (affiliate link). In his book, Ash provides tactical guidance for the customer development and market validation processes popularized by Eric Ries in the Lean Startup.

    The Lean Startup methods are fantastic, but we aren’t a startup, so we wanted to focus on intrapreneurship: driving value within a large corporation through risk-taking and innovation.

    In recent years, product teams have adopted agile approaches and the “lean” mentality: start small, iterate, learn, tune, scale. However, the pace of adoption of these concepts on the business side – marketing, sales, services, support – typically lags that of product. It turns out that the business’s primary interest is in protecting the status quo; the curent revenue and profit streams, not driving risky new innovations into the market. A thorough, scientific accounting and full understanding of any perceived disruption to the steady state is required for the business to get behind new product innovation.

    On the surface this seems like a reasonable expectation, but there is significant statistical evidence that knowing exactly where we’re going and having a detailed plan is much less important than our ability to embrace uncertainty by trying many small experiments. For more on that topic, check out the idea of convexity vs. understanding by Nassim Taleb, author of The Black Swan (affiliate link).

    While the merits of planning vs. experimenting are worthy of further discussion, this article is about ideas we discussed with Ash for working more closely with the business units to embrace the lean mindset, iterative discovery, and in-market learning. We noted several practical strategies for “de-risking” the process of in-market validation in partnership with the business:

    1) Validate your business model hypothesis within the smallest segment possible

    Market risk exists when there’s uncertainty about building a viable business. We can address market risk in stages. When we talk about the “next generation” of that business or changing the business model behind it, we generate fear. And fear often manifests as political posturing and defensive, protectionist tactics.

    We should search for a learning ground that is acceptable for both the business and the product team. For example, if we desire to replace the flagship product because of technical limitations and risk, we should choose a small corner of the existing installed base to test something new. We must achieve small successes to gain the trust and demonstrate the value necessary to take on successively larger amounts of risk.

    2) Focus on one objective at a time, e.g. existing or new customers?

    Using experiments and innovation accounting to “define, measure and communicate progress” is key (see How We Use Lean Stack for Innovation Accounting). To be effective these efforts must have focus. For example, we may be working on a replacement strategy for an existing product, but we also believe that new product will allow us to attract new customers. The experiments and resulting outcomes are discrete and we should test them independently.

    Using Ash’s Lean Canvas approach, we can model the opportunities, assumptions, market segments and implications independently and design tests relative to each set of realities. Compartmentalizing these efforts allows us to focus and avoid muddling results of our discovery in each area.

    3) Win early adopters within the business

    Just like we find early adopter users, we have to find early adopters of the vision within the business. They will need to take a leap of faith with you, and as can act as champions within the business as we achieve incremental success. As successes grow, we can expand the circle of business early adopters until the product/innovation is ready to become mainstream.

    4) Do all of this very quickly

    The speed in which we execute matters. As a best practice, new ideas and market opportunities should be defined and validated within 3-6 months. This is not only a good, Lean practice, it’s the key to building trust within the business. When market validation activities 12-18 months or more, folks get impatient and concerns rise. Questioning investment levels and applying pressure for plans and checklists doesn’t help matters, because until there is in-market validation, any and all plans regarding the trajectory of a business are purely speculative.

    In fact, best practice may be to launch a charter program in 3-6 months before asking for any formal business unit buy-in. It’s my opinion, however, that having someone from the business participate in the experimentation is absolutely critical to long-term success. But they must be versed in the lean mindset and approach the process in an entrepreneurial way.

    In conclusion…

    It was a great opportunity to talk to a leader in the field of lean methodologies. The discussion further affirmed for me that the lean approach can work inside an established business if we do the things I mention above. The business craves knowledge and understanding and the best way to learn and achieve those assurances is in small, digestible chunks. We will never get around the fact that there is no crystal ball. The future is inherently uncertain. The business and product innovation teams must share this understanding and build plans together that encourage rapid learning through experimentation in market instead of inside-out plans that assume specific outcomes.

     

     

     

     

    Categories: Business of Software, Culture, Innovation, Product Market Fit, SaaS.

  4. What really makes a team agile?

    I hear and read a lot about the zen of agile, scrum, Kanban, etc. these days (actually for the past decade+). But I don’t buy in to the theory that time boxes, daily stand ups and sprint reviews make a team agile. What matters infinitely more is how we engineer software and release processes to shorten the feedback/response loop.

    Here are a few questions to test a team’s agility:

    How long after releasing code do you get user feedback?

    Do you generate and monitor real-time business and usage analytics for your product?

    How quickly can you respond to user and analytical feedback with product updates?

    Can you release whenever you want to?

    Is your testing automated?

    Frankly, it matters less what internal processes you use to drive the work the team does. I say whatever works for the team which is likely to include best practices from multiple methodologies.

    What matters more, and really makes teams agile, is an ability to ship and iterate quickly based on real user and market feedback.

    Code that’s checked into version control but not in the hands of users is like inventory sitting in a warehouse. Hidden costs abound. A tight feedback and response loop supported by strong engineering practices is the hallmark of a truly agile team.

    Categories: Agile, Product Development.

  5. Everyone interacts with users

    I just spent two days with 45 users representing 17 customers along with several colleagues including some of my engineering team, and I was reminded that when engineers interact with users, fantastic things happen. Problems are understood deeply, clearly, and solutions are conceived.

    When software companies get big, employees are organized by function. While necessary on one hand we do a terrible disservice to users when divide responsibilities. For instance, product managers are responsible for understanding the user problems they want to solve, designers are responsible for prototyping solutions, and engineers are responsible for crafting the final product.

    In this process, there are multiple handoffs resulting in lost fidelity as we transition from problem definition to solution. Wouldn’t it be better if the engineer, designer and product manager were interacting with the user firsthand?

    In my experience, some of the best design insights come from engineers, value definition is clarified by clear-thinking designers, and product managers can drive key technical decisions. In a traditional organization with rigid role definitions, these occurrences would not be possible. Everyone looses, especially users.

    So my thesis is this: If everyone in your org is interacting directly with customers in some way, my guess you are building better products faster. If not you’re losing productivity and innovation opportunities that can be gained by applying the best and brightest minds in the building directly to customer problems

    Update: Case in point, Just ran across this article on British Airways launching a program to put tech staff on flights with customers.

    Categories: 100 words per day, Design, Product Development, Product Discovery.

  6. Unsubscribing

    This morning I unsubscribed from a bunch of email lists that I’m even not sure how I got onto.

    If you’re an email marketer, listen up: If I seek out the tiny “unsubscribe” link at the bottom of your email, please assume that my intent is to unsubscribe from all emails. I don’t want to decipher your form, re-type my email address, or manage my profile.

    Out of seven, there was only one that allowed me to unsubscribe with one click on that tiny unsubscribe email link. Kudos to them.

    Creating a great user experience means not overlooking any customer or prospect interaction – even the unsubscribe. If you don’t respect my time when I’m not your customer, will you respect it if I become one?

    Categories: 100 words per day, User Experience.

  7. Communicating value

    Product managers have the challenge and privilege of associating the work of engineers to the value created for customers and users. But all too often, we bombard our listeners with details that aren’t relevant to our story.

    Often times organizational and personal value is derived, like this:

    Thanks to the Acme Software, I can do in three days what used to take me three weeks. As a result I get to focus on activities of higher value to my organization.

    – or –

    Because of the new capabilities of Acme’s software, I was able to spend time with my wife and kids over the holidays even though I had looming deadlines in December.

    But sometimes we communicate like this:

    The new release of Acme’s software allows users to process invoices and easily run quarterly reports.

    Really? That’s great! (not really)

    Some product people are primarily responsible for driving customer discovery and development as product owners, while others are more focused on taking a product to market. Some of us do both, and if you’re in a startup environment you might even be coding as well. We have to get ourselves out of implementation mode when presenting a product’s value to the market and stakeholders.

    I find it especially helpful to have one on one discussions with users who are willing to share personal stories about working with your product and the value they’ve derived from it. These are also known as references.

    It’s not what your product does, it’s the impact it leaves behind that makes it special. Are your stories about features or impact?

     

    Categories: Product Marketing.

  8. Navigating Chrome tabs with the keyboard

    I’m almost embarrassed to publish this, but I just learned to navigate tabs in Chrome with keyboard shortcuts thanks to this Google Group post. From the post:

    • Next tab (from current): CTRL + Tab (mac) / CTRL + PgDown (Win)
    • Previous tab: CTRL + Shift + Tab / CTRL + PgUp
    • Specific tab: CMD + 1 to CMD + 8
    • Last tab: CMD + 9
    • Open previously closed tab: CMD + Shift + T (thanks, @willia4!)

    This will literally save me hours over the next few years of my life. Can’t believe I hadn’t Googled it until today…

    Categories: Productivity.

  9. This week’s Heroku debacle

    A blog post went viral this week and uncovered an issue in PaaS provider, Heroku’s routing mesh, which has caused a significant degradation of Ruby on Rails app performance. Essentially, over the past three years Heroku moved from “smart” to “random” web request routing among an account’s “dynos”, Heroku’s processing units. Each dyno runs about $35/month.

    The change in architecture, which is explained in detail here, is only a portion of why Heroku is catching heat. Here are the real reasons:

    Same cost, less value

    First and foremost, there have been no reductions in price for the net reduction in capacity provided by the service. This is especially frustrating to the community at a time when other PaaS providers like Amazon Web Services (AWS) continue to lower their prices. Heroku’s platform leverages AWS in its architecture. Over time, users were purchasing more dynos for their accounts with diminishing returns. Each additional $35 dyno does not provide $35 in value.

    Appearance of deception

    Second, Heroku boasts robust monitoring tools that allow you to see the performance of your applications across many layers of their architecture. However, the monitoring tools provided by Heroku and New Relic don’t reflect the area of latency caused by random request routing. For a highly sophisticated platform provider, this oversight comes across to the community as deceptive rather than as an oversight.

    Lack of coherent communication

    Finally, there was no communication to customers about the change, and no consistent and coherent documentation. In fact, documentation around Heroku’s site was confusing and contradictory. Again, the appearance of deception.

    Response

    Heroku is responding openly and humbly, which is the proper way to handle the situation, but there are many who don’t think the responses go far enough. They want monetary reparations as well. I’d guess Heroku is considering concessions quietly by necessity as they are part of a publicly traded company and any concessions could have an impact on current and prior period financials of the company.

    The whole debacle reminds us that the lack of transparency over time can cause much larger PR problems for companies than the issues themselves. Individual customers have the platform to tell their story and initiate change.

    Categories: Business of Software, Platforms, Technology.

  10. Using Font Awesome with Rails asset pipeline

    To use Font Awesome with a Rails app and the asset pipeline, add the following lines to config/environments/development.rb

    In the font-awesome.css file, just reference the file name of each font file (rather than referencing the containing directory):

    Thanks to Ashitaka for this stackoverflow response.

    Not sure if this will work with Heroku, will find out shortly.

    Categories: Rails Notes.

  11. Just ship it already

    As much as I advocate shipping to learn, I was called to the floor this week for not shipping a small product I’ve been working on. My initial reaction was indignant. But upon further reflection, I realized that all of the excuses I’ve been making for not shipping are just not good enough:

    • There isn’t enough functionality just yet
    • Usability isn’t perfect
    • The reports aren’t right
    • The business unit isn’t quite ready
    • There are manual deployment steps for the product
    • Etc…

    You know why they aren’t good enough excuses? Because each of these issues (for this particular product) will only take small amounts of effort to resolve. It’s when we treat the collection of small things as a big thing, “the product just isn’t ready,” that we lose sight of the opportunity cost of not shipping.

    I can respond to each bullet above with one question: what learning opportunities am I missing as a result of not being in the market right now.

    We don’t need the extra functionality to make an impact

    Usability will never be perfect, but we’ll never learn what it should be without real usage

    Those reports are the ones that the users really need

    The business unit is hungry for the opportunity this product will provide to improve margins

    Early adopters will deal with the manual deployment headaches

    Just ship it already. To ship is to choose.

    Categories: 100 words per day, Agile, Product Management.

  12. One Spark, Jacksonville, FL

    If I asked you to list where the next big innovation hub on the east cost of the US will be, chances are Jacksonville, FL wouldn’t be one in your top three.

    However, One Spark, inspired by SXSW and Kickstarter threatens to change that:

    Think SXSW meets ArtPrize meets Kickstarter.

    For five days in April 2013, Creators from around the globe will showcase art and innovation for a chance to score funding via:

    - $250,000 crowdfund (distributed by public vote)
    - Up to $1 million in capital investments (courtesy of STACHE Investments Corp.)
    - Immediate individual contributions (any amount, any project)

    While comparison pitches don’t do it for me, this event is interesting for a number of reasons. First, it’s only 4 hours from where I live. Second, it’s backed by some pretty serious money. Third, it’s open to everyone who creates anything. From the One Spark web site:

    What are you working on? Share your ideas and projects with the world by registering for One Spark 2013. One Spark connects you with the audience, support, and funding you need to take your work to the next level and beyond.

    It dawned on me that anyone who is even remotely invested in an idea or a side project would be crazy not to take advantage of the opportunity to register as a creator for this event.

    Why?

    A built-in deadline. MVP’s can be put together fast, One Spark is 2.5 months from today.

    Concentration of early adopters. Early adopters aren’t only helpful, they are critical to launching your product. They will participate even when it’s not complete enough to meet the needs of your target market so you can get feedback.

    Connect with like-minded individuals. Artists, musicians and other creators.

    Categories: 100 words per day, Innovation, Minimum Viable Product, Product Market Fit, Startups.

  13. The install base gap

    Nearly 60% of all iOS devices ever sold are running iOS 6 (Edible Apple).

    The gap continues to widen between the fragmented ecosystem that is Android and the up-to-date iOS installed base. This has massive implications for the application development ecosystem that drives each of these platforms.

    By contrast, Only 1.2% of Android users are on the latest version of the Android operating system. The majority are still on Gingerbread which was initially released late in 2010.

    This page for Android developers explains:

    …how to prioritize the development of your application features for the devices currently in the hands of users.

    This means that the great features being added to the OS today won’t be leveraged by users for years. To me this represents a fundamental flaw that will forever haunt the Android ecosystem relative to its biggest rival, iOS.

    Categories: 100 words per day, Platforms.

  14. Organizing platform development

    Dealing with shared services (AKF Partners blog) strikes a chord for a platform product manager. I can attest to the issues that arise with shared platform teams: overloaded backlogs, undecipherable priorities, increased time to market, loss of ability to drive innovation.

    In the end, platform must exist to increase the speed of software products to market. As soon it becomes an encumbrance, it should be re-imagined, replaced or removed altogether. From the article:

    Remember, whatever mechanisms you put in place, your shared service or tools team should be a gas pedal and not a break for TTM.

    During planning, teams will regularly take dependencies on platform to deliver necessary features for their market. When all of the requests are summed up, many teams will be let down because their requests cannot be fulfilled.

    So, the suggestion to run internal platform components similarly to open source projects is a good one and is a fertile middle ground between complete lockdown and utter chaos. It does, however, come with taxes in the form of code reviews, merges, documentation and collaboration with other contributors. But running platform in this way allows continued innovation and a strategic roadmap while putting more control into the hands of product teams.

     

    Categories: Platforms, Product Development, Technology.

  15. Prioritize shipping

    I love Jeff Atwood (@codinghorror). Here’s an excerpt of a presentation he calls How to stop sucking and be awesome instead:

    stopsucking

    Innovative software product teams are prioritizing release engineering and the ability to rapidly iterate over any single feature in the backlog because ability to ship product faster means the cost of making a mistake goes down dramatically. And we all make mistakes. Ship again to resolve a bug, ship again to add missing features, ship again to improve usability, ship again to… you get it.

    This mindset permeates every decision the team makes right down to the platforms they choose to build upon. Automation matters, ability to A/B test features matters, online deployment matters, and supporting all of this, an open ecosystem matters.

    In a SaaS world rapid iteration is not negotiable. We need to learn from our users and respond to their needs in real time. Solid release vehicles are the mechanism by which this happens.

    More reading:

    Categories: Uncategorized.

  16. Do you talk about your problems?

    Question about your company culture: Do you regularly talk about your problems? Openly? Is it okay to argue publicly? With your boss? With a VP or the CEO?

    If you answered no to any of these questions, you may have a groupthink problem. From wikipedia (emphases mine):

    Groupthink is a psychological phenomenon that occurs within a group of people, in which the desire for harmony or conformity in the group results in an incorrect or deviant decision-making outcome. Group members try to minimize conflict and reach a consensus decision without critical evaluation of alternative ideas or viewpoints, and by isolating themselves from outside influences.

    I have a firm belief that progress is made through constructive conflict. When I sense that there is too much agreement among a team for too long, I question whether that team is succumbing to groupthink.

    Now, I’m not saying that teams should never get aligned around ideas and plans. At some point we have to normalize and row in the same direction. But from time to time, someone should step back and make sure the direction we’re is rowing in is a good one.

    I’m also not condoning destructive conflict. Once a resolution is reached, the team should be able to go out and enjoy a beer together, knowing they’ll slog it out again tomorrow. People who care enough to argue, typically care deeply about the subject they’re arguing about and this is a very good thing.

    Passion enables great products. Groupthink sucks.

    Categories: 100 words per day, Culture, Product Development.

  17. All in perspective

    Today was a challenging day on many fronts, not the least of which the the loss of a colleague. This event puts all others in perspective (of course) and reminds me that we have only a relative few moments to enjoy our time here on Earth with the ones we love.

    Tonight I’ll hug my kids and my wife a little tighter. I’ll call my family to catch up which I neglect to do often enough. And I’ll recommit to spending more time doing the things I enjoy and less time on things that aren’t important.

    Rest in peace, friend.

     

    Categories: Personal.

  18. Software with an opinion

    Choice sucks. Have you ever found yourself standing in the grocery isle faced with the daunting decision of which diced canned tomatos to buy? Petite or large, with chili’s or without, roasted garlic or not. The amount of choice we have in this country (USA) is insane and it can be paralyzing.

    Photo Credit: TheeErin

    So it is with software which is why we should work hard to give our products an opinion.

    Software with an opinion doesn’t have 10′s or 100′s of configuration options just so it’ll work for everyone. For consumer software, configuration choices are burdensome barriers to adoption. Too many choices in an enterprise software package makes it expensive to implement and extends the time it takes to get a customer live.

    Software with an opinion makes the hard choices required to support a set of targeted users directly and unabashedly. Choose the primary users who must be satisfied by your product and do everything in your power to delight them, even at the exclusion of everyone else.

    Don’t try to be all things to all people because your product won’t be relevant to anyone.

    Categories: 100 words per day, Business of Software, Design, Minimum Viable Product.

  19. All ideas respond to work

    Pulitzer prize recipient, Tracy Kidder, says of writing:

    That you can learn to write better is one of our fundamental assumptions. No sensible person would deny the mystery of talent, or for that matter the mystery of inspiration. But if it is vain to deny these mysteries, it is useless to depend on them. No other art form is so infinitely mutable. Writing is revision. All prose responds to work.

    By the same virtue, don’t all ideas respond to work as well? Two ingredients are absolutely critical for turning an idea into something real. One, is the ability to accept that the idea must be shared, revised and refined before it can become real. The possibility existis (and is likely) that our initial theories on a matter are completely and utterly wrong.

    The second ingredient is work in the form of execution. Beginning to work on the idea allows you to determine if there’s something there. Or maybe you’ll uncover a completely different opportunity. But neither outcome is possible if you don’t start doing something.

    Chances are that the original idea is going to be wrong in some way. But in the process of learning that, you can uncover other hidden gems. For a great example of this, check out Heroku’s epic pivot which took them from web-based Ruby IDE to Platform as a Service bought by Salesforce.com for $212MM in 2011.

    Categories: 100 words per day, Business of Software, Platforms, Product/Market Fit.

  20. Why I write code

    As I’ve written previously, while my career started as a fulltime engineer, I’ve steadily drifted away from hands-on programming in my day job. I do, however, continue to write software in my spare time. I usually don’t get started until 8 or 9 at night after the kids are in bed (when I’m basically spent), and I don’t really accomplish all that much – 30-60 minutes a day does not world-class engineer make.

    Like writing, though, I find coding therapeutic if not incredibly frustrating at times. I can get stuck on a bug or misunderstanding of a new JavaScript framework for days. But when I break through, my horizons are expanded and my brain feels like it’s been thoroughly exercised.

    Coding also helps me in my day job, software product management. It’s a good reminder of the realities my engineering teams  face day to day.

    Maybe one day I’ll get back to writing software fulltime; I’ve always feared losing those skills completely. For now it’s just a hobby and a secret weapon to be used only when the best inspiration for a product idea strikes.

    Categories: 100 words per day, Product Management.

  21. Driving strategy with execution

    I’m growing increasingly bored with the concept of product strategy. Having a strategy is not a bad thing, and in fact, you should have a vision of where you want to take your product.

    What bugs me more is how we arrive at our strategies. I find many times that strategy is introspective and often conceived within the confines of corporate meeting rooms and offices.

    ferrell-bush-strategery

    “Strategery”

    But perhaps it’s better to let tactical execution drive what becomes strategy. In his book, Behind the Cloud, Marc Benioff Salesforce.com Founder and CEO describes how Salesforce arrived at it’s early marketing strategy of leveraging their largest competitor’s events to pitch the virtues of CRM in the cloud.

    They based a successful mock protest against “traditional software” outside of Moscone Center at Siebel’s annual conference, and quickly determined that this guerrilla marketing tactic would be an ongoing component of their overall marketing strategy in the years to come.

    The protest wasn’t a sure bet; it could have failed miserably (like another shenanigan involving the Dalai Lama). But it didn’t fail. Even if it did, chances are, the losses would have been minimal. Surely there were hundreds of other tactical bets that didn’t work out as well either.

    Conception and meticulous planning of strategy without tactical execution to test our ideas results in forced execution when it may no longer make sense. In my experience, the best laid plans are often obsolete within days or weeks after execution begins. It’s okay to be wrong, but only in small increments and for short periods of time.

    Categories: 100 words per day, Innovation, Minimum Viable Product.

  22. MVP, it’s not just for users anymore

    In his book, The Lean Startup, Eric Ries outlines the approach Dropbox took when they encountered difficulties convincing investors that the world needed another online file backup product. Their MVP was a video which showed in detail how the product would work, even before it was built. The release of the video resulted in tens of thousands people who signed up to use the product when it shipped. $250MM in funding later, and the rest is history.

    MVP is not really a product, it’s a tool used communicate, validate and refine a vision. And the bigger the vision, the more important it is to illustrate it. In traditional corporate America, we’re constantly building Power Points, spreadsheets and documents that use words to describe our ideas. But there comes a point in time when the vision is too large for words.

    When that time arises, it’s time to break away from words and show, not tell with prototypes, videos or other tangibles which articulate your story. Using the MVP you create to gather valuable feedback from your colleagues and fold it back into the vision, making it iteratively more tangible.

    In larger companies we have a tendency to avoid radical ideas in favor of the safe bet. There are many factors that cause this, but not the least of which is fear of failure and the unknown. If we can use an MVP to paint a vision that our colleagues can see, we’ll be much more likely to garner broader support, energy, and long-term innovative success as a company.

    Drew Houston‘s Dropbox MVP video:

    (word count: 267)

    Categories: 100 words per day, Business of Software, Minimum Viable Product, Product Discovery, Product Management.

  23. Over deliver

    One of the key responsibilities of the Product Manager is to ensure more is delivered than was expected by customers, business units or other constituents. PM’s have the ability to set expectations as well as drive delivery so in theory this should never really be an issue.

    The founder of my last company had a formula that looks something like this:

    20121021-094053.jpg

    Delivery – Expectations = Satisfaction

    You don’t ever want the equation to come out negative. George Washington writes in Rules of Civility

    Undertake not what you cannot perform but be careful to keep your promise.

    Quietly solve the problems that make an impact for your market. Optimization is fine, as long as it’s moving the needle for existing customers, creating more references.

    Categories: 100 words per day, Business of Software, Product Management.

  24. HTML5 is for the web, and the mobile web

    I agree with all of the points made that Stefan Fidanov makes in HTML5 is for the web, not mobile apps, but there’s another important point to pile on: not every mobile scenario requires an app.

    Users browse content on the web with mobile browsers. In my opinion, this is where HTML5 mobile frameworks like jQuery Mobile and Sencha really shine. My experience developing a jQuery Mobile app supports Stefan’s points. There were messy workarounds for caching, issues with OAuth redirects and the related behavior of the mobile browser, and limited (even if evolving) ability to integrate with native device features.

    There are far too many apps out there which attempt to segment their content from the rest of the internet. I’m sorry, but I don’t need the USA Today app or The Daily, but it would be nice to land on an article and get a tailored rendering for my mobile browser. Native apps are the wrong solution for broad content from a single source – like what a newspaper would publish - it’s HTML5 they need.

    Categories: Uncategorized.

  25. Just ship something

    Over the years my career has transitioned from hands-on engineering, to management, and ultimately product management. Back in 2010, to maintain some sense of technical relevance, I began dabbling in new, mainly open source, programming languages and frameworks. Ruby on Rails, Python, PHP, you name it, I was reading about it, installing it, running the samples, and moving on to the next thing.

    But in 2012 I made the decision to stop dabbling and start focusing on one idea end to end, no matter how small or insignificant. I forced myself to play designer, engineer/qa and product manager all at the same time. Did I release a blockbuster iOS app? No, but I did get the satisfaction of taking an idea from concept to shipping, and shipping teaches you more than dabbling.

    It teaches you about the headaches of actually getting something done on a platform, the idiosyncrasies of deployment, what makes a design usable, and the effort required to make something that you’re proud to share with your friends and family.

    If you’re like me and wake up one morning with the feeling that you’ve lost that technical edge, resolve to just ship something. With an endless choice of cloud platforms and free, open source technologies, it’s never been easier, and you’re sure to benefit from the satisfaction and eduction of doing it.

     (word count 223)

    Categories: 100 words per day, Giftr, Goal Setting.

© Copyright Jay Nathan, 2010-2013