Loading ...
Sorry, an error occurred while loading the content.
 

Death by competitive analysis

Expand Messages
  • William Pietri
    As somebody who is deeply involved in internet startups, I ve been very excited lately by the rise of the Lean Startup movement. Basically, it combines Agile
    Message 1 of 14 , Mar 3, 2010
      As somebody who is deeply involved in internet startups, I've been very
      excited lately by the rise of the Lean Startup movement. Basically, it
      combines Agile development with a raft of business-side practices into
      an integrated process for creating a new product. The core feedback loop
      looks like this:

      http://www.ashmaurya.com/wp-content/uploads/2009/12/buildmeasurelearn.jpg

      I really like the balance between research, design, and construction
      suggested there.


      I mention this because of this relevant article from Steve Blank, "Death
      by Competitive Analysis":

      http://entrepreneur.venturebeat.com/2010/03/03/death-by-competitive-analysis/

      It has an interesting take on a theme that has come up here a lot:
      understanding real user needs. In particular, it talks about a classic
      product design mistake: taking a competitive analysis document and
      turning that in a list of features for the first version of a product.
      Instead, he strongly encourages going out and engaging with actual
      customers to understand their needs.

      That's nominally an obvious theme, but having seen people make exactly
      this mistake, I really enjoyed the article.

      William
    • Fredrik Matheson
      Thanks for sharing! For a nice framework that lets you compare you vs. your competitors *and* figure out what needs/wants that should be satisfied (but not
      Message 2 of 14 , Mar 3, 2010
        Thanks for sharing!

        For a nice framework that lets you compare you vs. your competitors *and* figure out what needs/wants that should be satisfied (but not over-satisfied), take a look at What Customers Want by Anthony Ulwick.

        (Sadly, the framework isn't available in the preview from Google Books)

        - Fredrik
      • Glen B. Alleman
        Having done 2 startups - one that failed one that went public (www.triconex.com)- I know of no other way to get the first article. Is these really new in the
        Message 3 of 14 , Mar 3, 2010
          Having done 2 startups - one that failed one that went public
          (www.triconex.com)- I know of no other way to get the first article.
          Is these really "new" in the sense that it is a new way of doing start ups?

          Glen Alleman

          -----Original Message-----
          From: agile-usability@yahoogroups.com
          [mailto:agile-usability@yahoogroups.com] On Behalf Of William Pietri
          Sent: Wednesday, March 03, 2010 12:08 PM
          To: agile-usability@yahoogroups.com
          Subject: [agile-usability] Death by competitive analysis


          As somebody who is deeply involved in internet startups, I've been very
          excited lately by the rise of the Lean Startup movement. Basically, it
          combines Agile development with a raft of business-side practices into
          an integrated process for creating a new product. The core feedback loop
          looks like this:

          http://www.ashmaurya.com/wp-content/uploads/2009/12/buildmeasurelearn.jpg

          I really like the balance between research, design, and construction
          suggested there.


          I mention this because of this relevant article from Steve Blank, "Death
          by Competitive Analysis":

          http://entrepreneur.venturebeat.com/2010/03/03/death-by-competitive-analysis
          /

          It has an interesting take on a theme that has come up here a lot:
          understanding real user needs. In particular, it talks about a classic
          product design mistake: taking a competitive analysis document and
          turning that in a list of features for the first version of a product.
          Instead, he strongly encourages going out and engaging with actual
          customers to understand their needs.

          That's nominally an obvious theme, but having seen people make exactly
          this mistake, I really enjoyed the article.

          William


          ------------------------------------

          Yahoo! Groups Links
        • Mike Dwyer
          Only of you ignore history, something our profession excels at. Sent via BlackBerry by AT&T ... From: Glen B. Alleman Date:
          Message 4 of 14 , Mar 3, 2010
            Only of you ignore history, something our profession excels at.

            Sent via BlackBerry by AT&T


            From: "Glen B. Alleman" <glen.alleman@...>
            Date: Wed, 3 Mar 2010 12:54:36 -0700
            To: <agile-usability@yahoogroups.com>
            Subject: RE: [agile-usability] Death by competitive analysis

             

            Having done 2 startups - one that failed one that went public
            (www.triconex. com)- I know of no other way to get the first article.
            Is these really "new" in the sense that it is a new way of doing start ups?

            Glen Alleman

            -----Original Message-----
            From: agile-usability@ yahoogroups. com
            [mailto:agile-usability@ yahoogroups. com] On Behalf Of William Pietri
            Sent: Wednesday, March 03, 2010 12:08 PM
            To: agile-usability@ yahoogroups. com
            Subject: [agile-usability] Death by competitive analysis

            As somebody who is deeply involved in internet startups, I've been very
            excited lately by the rise of the Lean Startup movement. Basically, it
            combines Agile development with a raft of business-side practices into
            an integrated process for creating a new product. The core feedback loop
            looks like this:

            http://www.ashmaury a.com/wp- content/uploads/ 2009/12/buildmea surelearn. jpg

            I really like the balance between research, design, and construction
            suggested there.

            I mention this because of this relevant article from Steve Blank, "Death
            by Competitive Analysis":

            http://entrepreneur .venturebeat. com/2010/ 03/03/death- by-competitive- analysis
            /

            It has an interesting take on a theme that has come up here a lot:
            understanding real user needs. In particular, it talks about a classic
            product design mistake: taking a competitive analysis document and
            turning that in a list of features for the first version of a product.
            Instead, he strongly encourages going out and engaging with actual
            customers to understand their needs.

            That's nominally an obvious theme, but having seen people make exactly
            this mistake, I really enjoyed the article.

            William

            ------------ --------- --------- ------

            Yahoo! Groups Links

          • William Pietri
            ... The Lean Startup stuff? Nothing is truly new under the sun; many claimed there was nothing new about Agile, either. But I think there are several things
            Message 5 of 14 , Mar 3, 2010
              On 03/03/2010 11:54 AM, Glen B. Alleman wrote:
              Having done 2 startups - one that failed one that went public
              (www.triconex.com)- I know of no other way to get the first article.
              Is these really "new" in the sense that it is a new way of doing start ups?
                

              The Lean Startup stuff? Nothing is truly new under the sun; many claimed there was nothing new about Agile, either. But I think there are several things that distinguish the Lean Startup from both the general-issue Silicon Valley approach and the standard Agile approach:

              • It's more extreme than XP. For example, instead of just Continuous Integration, the Lean Startup approach recommends Continuous Deployment, where you push to production on every checkin. IMVU, for example, releases  ~50x/day.
              • There are no requirements; there are only hypotheses in need of testing.
              • It is focused on users, customers, and markets, rather than grand visions or product plans.
              • It has a heavy dose of Lean, especially in its approach to cycle time, bug reduction, process refinement, and waste reduction.
              • Rather than a generic software development process, it is an integrated approach to creating a company, with the focus on inventing/discovering a new product.
              • It is specifically for creating new products, often ones that disrupt existing markets.
              • It avoids the "achieving a failure" scenario [1] of big-bang startups.
              • It splits the process into two different phases: before and after product-market fit is demonstrated.
              • Average capital requirements are substantially lower.
              • With its concept of a pivot (radical change in product direction based on feedback), it explicitly encourages a learning-oriented approach to product creation.
              • Its focus on minimum viable product (MVP) strongly encourages release-early, release-often behavior.

              For folks interested in the business side of this, and how it fits into the history of Silicon Valley startups, I strongly recommend Steve Blank's blog:

              http://steveblank.com/

              For the other side of it, how the Lean Startup works in practice and its relationship to the Agile world, Eric Ries's blog is the source:

              http://www.startuplessonslearned.com/

              William




              [1] http://www.startuplessonslearned.com/2009/01/achieving-failure.html
            • mark schraad
              There truly is not a lot new here. Most of agile is borrowed from design (iterative work, early prototypes, user testing, mini-meetings... et al) and the
              Message 6 of 14 , Mar 3, 2010
                There truly is not a lot new here. Most of agile is borrowed from design (iterative work, early prototypes, user testing, mini-meetings... et al) and the notion of being in the field with customers... well doh... designers in chicago adopted ethnographic methods back in the early 90's. Competitive analysis is a great tool... but the example shown in the article is pretty lame. There are much better methods and formats. Business and design (and maybe dev folks as well) should be doing their own competitive analysis. The different perspectives all render worthwhile insights.




                On Wed, Mar 3, 2010 at 8:02 PM, William Pietri <william@...> wrote:
                 

                On 03/03/2010 11:54 AM, Glen B. Alleman wrote:
                Having done 2 startups - one that failed one that went public
                (www.triconex.com)- I know of no other way to get the first article.
                Is these really "new" in the sense that it is a new way of doing start ups?
                  

                The Lean Startup stuff? Nothing is truly new under the sun; many claimed there was nothing new about Agile, either. But I think there are several things that distinguish the Lean Startup from both the general-issue Silicon Valley approach and the standard Agile approach:

                • It's more extreme than XP. For example, instead of just Continuous Integration, the Lean Startup approach recommends Continuous Deployment, where you push to production on every checkin. IMVU, for example, releases  ~50x/day.
                • There are no requirements; there are only hypotheses in need of testing.
                • It is focused on users, customers, and markets, rather than grand visions or product plans.
                • It has a heavy dose of Lean, especially in its approach to cycle time, bug reduction, process refinement, and waste reduction.
                • Rather than a generic software development process, it is an integrated approach to creating a company, with the focus on inventing/discovering a new product.
                • It is specifically for creating new products, often ones that disrupt existing markets.
                • It avoids the "achieving a failure" scenario [1] of big-bang startups.
                • It splits the process into two different phases: before and after product-market fit is demonstrated.
                • Average capital requirements are substantially lower.
                • With its concept of a pivot (radical change in product direction based on feedback), it explicitly encourages a learning-oriented approach to product creation.
                • Its focus on minimum viable product (MVP) strongly encourages release-early, release-often behavior.

                For folks interested in the business side of this, and how it fits into the history of Silicon Valley startups, I strongly recommend Steve Blank's blog:

                http://steveblank.com/

                For the other side of it, how the Lean Startup works in practice and its relationship to the Agile world, Eric Ries's blog is the source:

                http://www.startuplessonslearned.com/

                William




                [1] http://www.startuplessonslearned.com/2009/01/achieving-failure.html


              • Mike Dwyer
                William The big false positive in this argument is the continuous deployment. Remember the annoying browser wars with the unending interruptions to using the
                Message 7 of 14 , Mar 3, 2010

                  William

                  The big false positive in this argument is the continuous deployment.  Remember the annoying browser wars with the unending interruptions to using the web caused by the incessant and annoying updates?  That is one reason, but the best is when your customers call and beg you to stop sending them stuff because they cannot absorb it as quickly as you can deliver it up.  You have to keep in mind that you are part of a supply chain for information use.  What you deliver needs to be integrated into your customer’s environment.  Now this may sound strange but it happens when you start dealing with groups of users.

                   

                  Mike Dwyer
                  Principal Agile Consultant

                  BigVisible Solutions
                  url:    http://www.bigvisible.com

                  cell:   (978) 376-4422

                  email: mdwyer@...

                   

                   

                   

                  From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of mark schraad
                  Sent: Wednesday, March 03, 2010 9:33 PM
                  To: agile-usability@yahoogroups.com
                  Subject: Re: [agile-usability] Death by competitive analysis

                   

                   

                  There truly is not a lot new here. Most of agile is borrowed from design (iterative work, early prototypes, user testing, mini-meetings... et al) and the notion of being in the field with customers... well doh... designers in chicago adopted ethnographic methods back in the early 90's. Competitive analysis is a great tool... but the example shown in the article is pretty lame. There are much better methods and formats. Business and design (and maybe dev folks as well) should be doing their own competitive analysis. The different perspectives all render worthwhile insights.

                   

                   

                   

                  On Wed, Mar 3, 2010 at 8:02 PM, William Pietri <william@...> wrote:

                   

                  On 03/03/2010 11:54 AM, Glen B. Alleman wrote:

                  Having done 2 startups - one that failed one that went public
                  (www.triconex.com)- I know of no other way to get the first article.
                  Is these really "new" in the sense that it is a new way of doing start ups?
                    

                   

                  The Lean Startup stuff? Nothing is truly new under the sun; many claimed there was nothing new about Agile, either. But I think there are several things that distinguish the Lean Startup from both the general-issue Silicon Valley approach and the standard Agile approach:

                  • It's more extreme than XP. For example, instead of just Continuous Integration, the Lean Startup approach recommends Continuous Deployment, where you push to production on every checkin. IMVU, for example, releases  ~50x/day.
                  • There are no requirements; there are only hypotheses in need of testing.
                  • It is focused on users, customers, and markets, rather than grand visions or product plans.
                  • It has a heavy dose of Lean, especially in its approach to cycle time, bug reduction, process refinement, and waste reduction.
                  • Rather than a generic software development process, it is an integrated approach to creating a company, with the focus on inventing/discovering a new product.
                  • It is specifically for creating new products, often ones that disrupt existing markets.
                  • It avoids the "achieving a failure" scenario [1] of big-bang startups.
                  • It splits the process into two different phases: before and after product-market fit is demonstrated.
                  • Average capital requirements are substantially lower.
                  • With its concept of a pivot (radical change in product direction based on feedback), it explicitly encourages a learning-oriented approach to product creation.
                  • Its focus on minimum viable product (MVP) strongly encourages release-early, release-often behavior.


                  For folks interested in the business side of this, and how it fits into the history of Silicon Valley startups, I strongly recommend Steve Blank's blog:

                  http://steveblank.com/

                  For the other side of it, how the Lean Startup works in practice and its relationship to the Agile world, Eric Ries's blog is the source:

                  http://www.startuplessonslearned.com/

                  William




                  [1] http://www.startuplessonslearned.com/2009/01/achieving-failure.html

                   

                • William Pietri
                  ... If you re saying that there are ways to do Continuous Deployment wrongly, I don t think anybody would disagree with that. The interesting part to me is
                  Message 8 of 14 , Mar 3, 2010
                    On 03/03/2010 06:40 PM, Mike Dwyer wrote:
                    The big false positive in this argument is the continuous deployment.  Remember the annoying browser wars with the unending interruptions to using the web caused by the incessant and annoying updates?  That is one reason, but the best is when your customers call and beg you to stop sending them stuff because they cannot absorb it as quickly as you can deliver it up.  You have to keep in mind that you are part of a supply chain for information use.  What you deliver needs to be integrated into your customer’s environment.  Now this may sound strange but it happens when you start dealing with groups of users.


                    If you're saying that there are ways to do Continuous Deployment wrongly, I don't think anybody would disagree with that. The interesting part to me is that there appear to be ways to do it well.

                    William
                  • William Pietri
                    ... I guess if somebody had said, Hey, X is totally new in the history of the world and I am a genius for discovering it, then the X is not new response
                    Message 9 of 14 , Mar 3, 2010
                      On 03/03/2010 06:32 PM, mark schraad wrote: There truly is not a lot new here. Most of agile is borrowed from design (iterative work, early prototypes, user testing, mini-meetings... et al) and the notion of being in the field with customers... well doh... designers in chicago adopted ethnographic methods back in the early 90's.

                      I guess if somebody had said, "Hey, X is totally new in the history of the world and I am a genius for discovering it," then the "X is not new" response would be interesting to me.

                      But as far as I can tell, nobody is saying that. Ries and Blank have been pretty clear about the many things they're borrowing from, as were a lot of the early Agile people.

                      What is genuinely new -- and what I'm excited about, both with the Agile movement and with the Lean Startup -- is that people are actually using these techniques in large numbers, and they're using them together in ways that are synergistic.

                      Democracy isn't new either -- the ancient Greeks rightly get credit in the footnotes -- but I still think it's reasonable to be excited that a couple billion people have started using it and making it work in the last two centuries.

                      William

                    • mark schraad
                      Well, I suppose you get good marks for rhetoric here William, it is in fact hard to argue with a democracy metaphor lol. Nothing new here is nothing new.
                      Message 10 of 14 , Mar 3, 2010
                        Well, I suppose you get good marks for rhetoric here William, it is in fact hard to argue with a democracy metaphor lol.

                        Nothing new here is nothing new. 

                        Frankly... humans have yet to figure out how to efficiently or effectively develop software in an increasingly rapid change environment. Agile is an interesting side note in attempts to figure this puzzle out, but is far from the answer. Parts of the manifesto are fantastic. As a whole it is a failed process... the integration and recognition of IA and IX up front has helped it to inch towards being a worthwhile product development process. But there is a very long ways to go.

                        I am not trying to discredit any of these methods or processes, and certainly not the attempts made. And I do keep looking here for indications of a better innovation process. But looking to users for answers is not exactly rocket science or new thinking.

                        Respectfully,

                        Mark



                        On Wed, Mar 3, 2010 at 8:54 PM, William Pietri <william@...> wrote:
                         

                        On 03/03/2010 06:32 PM, mark schraad wrote:
                        There truly is not a lot new here. Most of agile is borrowed from design (iterative work, early prototypes, user testing, mini-meetings... et al) and the notion of being in the field with customers... well doh... designers in chicago adopted ethnographic methods back in the early 90's.

                        I guess if somebody had said, "Hey, X is totally new in the history of the world and I am a genius for discovering it," then the "X is not new" response would be interesting to me.

                        But as far as I can tell, nobody is saying that. Ries and Blank have been pretty clear about the many things they're borrowing from, as were a lot of the early Agile people.

                        What is genuinely new -- and what I'm excited about, both with the Agile movement and with the Lean Startup -- is that people are actually using these techniques in large numbers, and they're using them together in ways that are synergistic.

                        Democracy isn't new either -- the ancient Greeks rightly get credit in the footnotes -- but I still think it's reasonable to be excited that a couple billion people have started using it and making it work in the last two centuries.

                        William


                      • Glen B. Alleman
                        Mike, What agile answers - that has been answered in large construction, defense, and space programs for about a decade now - is how long are willing to wait
                        Message 11 of 14 , Mar 3, 2010

                          Mike,

                           

                          What agile answers – that has been answered in large construction, defense, and space programs for about a decade now – is “how long are willing to wait before you find out you’re late?”

                          The answer to this question results in the production of tangible deliverables (partial completion of the end product or useable intermediate products) on duration boundaries less (1/2 is common on our domains) that match the need for information about physical percent complete

                          On large defense and space programs we work, not work package (a single deliverable) can cross more than accounting period (a month). This means a WP can only be 45 work days long before a complete deliverable to some level of maturity must be produced for a 0%/100% assessment.

                          The hard part is to partition the program into tangible deliverables that represent assessment of progress for the rolling wave. This is the role of Systems Engineering and the Program Planning and Control staff.

                          “What does DONE look like,” must be answered in measures of physical percent complete – this is the basis of ANSI/EIA-748B and a myriad of DoD guidance.

                          This is independent of any method used to produce these artifacts – Scrum, XP, linear development, whatever. Doesn’t matter – but the question of how long is at a maximum 45 working days. This is on programs that last 5 to 7 years.

                           

                          Glen Alleman

                           

                          From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Mike Dwyer
                          Sent: Wednesday, March 03, 2010 7:41 PM
                          To: agile-usability@yahoogroups.com
                          Subject: RE: [agile-usability] Death by competitive analysis

                           




                          William

                          The big false positive in this argument is the continuous deployment.  Remember the annoying browser wars with the unending interruptions to using the web caused by the incessant and annoying updates?  That is one reason, but the best is when your customers call and beg you to stop sending them stuff because they cannot absorb it as quickly as you can deliver it up.  You have to keep in mind that you are part of a supply chain for information use.  What you deliver needs to be integrated into your customer’s environment.  Now this may sound strange but it happens when you start dealing with groups of users.

                           

                          Mike Dwyer
                          Principal Agile Consultant

                          BigVisible Solutions
                          url:    http://www.bigvisible.com

                          cell:   (978) 376-4422

                          email: mdwyer@...

                           

                           

                           

                          From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of mark schraad
                          Sent: Wednesday, March 03, 2010 9:33 PM
                          To: agile-usability@yahoogroups.com
                          Subject: Re: [agile-usability] Death by competitive analysis

                           

                           

                          There truly is not a lot new here. Most of agile is borrowed from design (iterative work, early prototypes, user testing, mini-meetings... et al) and the notion of being in the field with customers... well doh... designers in chicago adopted ethnographic methods back in the early 90's. Competitive analysis is a great tool... but the example shown in the article is pretty lame. There are much better methods and formats. Business and design (and maybe dev folks as well) should be doing their own competitive analysis. The different perspectives all render worthwhile insights.

                           

                           

                           

                          On Wed, Mar 3, 2010 at 8:02 PM, William Pietri <william@...> wrote:

                           

                          On 03/03/2010 11:54 AM, Glen B. Alleman wrote:

                          Having done 2 startups - one that failed one that went public
                          (www.triconex.com)- I know of no other way to get the first article.
                          Is these really "new" in the sense that it is a new way of doing start ups?
                            

                           

                          The Lean Startup stuff? Nothing is truly new under the sun; many claimed there was nothing new about Agile, either. But I think there are several things that distinguish the Lean Startup from both the general-issue Silicon Valley approach and the standard Agile approach:

                          • It's more extreme than XP. For example, instead of just Continuous Integration, the Lean Startup approach recommends Continuous Deployment, where you push to production on every checkin. IMVU, for example, releases  ~50x/day.
                          • There are no requirements; there are only hypotheses in need of testing.
                          • It is focused on users, customers, and markets, rather than grand visions or product plans.
                          • It has a heavy dose of Lean, especially in its approach to cycle time, bug reduction, process refinement, and waste reduction.
                          • Rather than a generic software development process, it is an integrated approach to creating a company, with the focus on inventing/discovering a new product.
                          • It is specifically for creating new products, often ones that disrupt existing markets.
                          • It avoids the "achieving a failure" scenario [1] of big-bang startups.
                          • It splits the process into two different phases: before and after product-market fit is demonstrated.
                          • Average capital requirements are substantially lower.
                          • With its concept of a pivot (radical change in product direction based on feedback), it explicitly encourages a learning-oriented approach to product creation.
                          • Its focus on minimum viable product (MVP) strongly encourages release-early, release-often behavior.


                          For folks interested in the business side of this, and how it fits into the history of Silicon Valley startups, I strongly recommend Steve Blank's blog:

                          http://steveblank.com/

                          For the other side of it, how the Lean Startup works in practice and its relationship to the Agile world, Eric Ries's blog is the source:

                          http://www.startuplessonslearned.com/

                          William




                          [1] http://www.startuplessonslearned.com/2009/01/achieving-failure.html

                           

                           




                        • Ron Jeffries
                          Hello, William. On Wednesday, March 3, 2010, at 9:54:41 PM, you ... I just wish we could learn it in the USA ... :) Ron Jeffries www.XProgramming.com
                          Message 12 of 14 , Mar 3, 2010
                            Hello, William. On Wednesday, March 3, 2010, at 9:54:41 PM, you
                            wrote:

                            > Democracy isn't new either -- the ancient Greeks rightly get credit in
                            > the footnotes -- but I still think it's reasonable to be excited that a
                            > couple billion people have started using it and making it work in the
                            > last two centuries.

                            I just wish we could learn it in the USA ... :)

                            Ron Jeffries
                            www.XProgramming.com
                            www.xprogramming.com/blog
                            Only the hand that erases can write the true thing. -- Meister Eckhart
                          • Mike Dwyer
                            Perhaps a discussion on the difference between a Repbulic and Democracy would be a good first start, but that would be a major step into this Rabbit Hole. Mike
                            Message 13 of 14 , Mar 4, 2010
                              Perhaps a discussion on the difference between a Repbulic and Democracy
                              would be a good first start, but that would be a major step into this Rabbit
                              Hole.


                              Mike Dwyer
                              "Planning constantly peers into the future for indications as to where a
                              solution may emerge."
                              "A Plan is a complex situation, adapting to an emerging solution." 
                              -----Original Message-----
                              From: agile-usability@yahoogroups.com
                              [mailto:agile-usability@yahoogroups.com] On Behalf Of Ron Jeffries
                              Sent: Wednesday, March 03, 2010 11:32 PM
                              To: agile-usability@yahoogroups.com
                              Subject: Re: [agile-usability] Death by competitive analysis

                              Hello, William. On Wednesday, March 3, 2010, at 9:54:41 PM, you
                              wrote:

                              > Democracy isn't new either -- the ancient Greeks rightly get credit in
                              > the footnotes -- but I still think it's reasonable to be excited that a
                              > couple billion people have started using it and making it work in the
                              > last two centuries.

                              I just wish we could learn it in the USA ... :)

                              Ron Jeffries
                              www.XProgramming.com
                              www.xprogramming.com/blog
                              Only the hand that erases can write the true thing. -- Meister Eckhart



                              ------------------------------------

                              Yahoo! Groups Links
                            • Mike Dwyer
                              It is good to hear there has been this much movement in the land of giga-mongo projects. Have you ever thought this might be also measure the gap between what
                              Message 14 of 14 , Mar 4, 2010

                                It is good to hear there has been this much movement in the land of giga-mongo projects.  Have you ever thought this might be also measure the gap between what was really simple as opposed to what people estimated their understanding of the clarity of WHAT was valuable and HOW to deliver that.   This convergence of How and What and the delta you can derive from assumption (aka estimate) and fact (aka accepted potential product) is a better estimate on what is viable? 

                                I bring this up because if you increase your sample rate from 45 days to 15 days, you would have 3X as many points of measure.  You would also be able to cost justify earlier forays into high value high risk elements that would further improve your visibility into “being late”.  Most of all you could implement the fail often fail fast succeed quickly maxim and shift POC funding for those items you absolutely gotta have.

                                 

                                After all this, you big guys might realize that it is your embracing of the ‘big’ that limits what you can do.  A measure of this change will be statements like this.  “How fast can you tell me where the envelope ends and what options do I have for making good  investment decisions quickly”

                                 

                                Mike Dwyer
                                Principal Agile Consultant

                                BigVisible Solutions
                                url:    http://www.bigvisible.com

                                cell:   (978) 376-4422

                                email: mdwyer@...

                                 

                                 

                                 

                                From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Glen B. Alleman
                                Sent: Wednesday, March 03, 2010 10:30 PM
                                To: agile-usability@yahoogroups.com
                                Subject: RE: [agile-usability] Death by competitive analysis

                                 

                                 

                                Mike,

                                 

                                What agile answers – that has been answered in large construction, defense, and space programs for about a decade now – is “how long are willing to wait before you find out you’re late?”

                                The answer to this question results in the production of tangible deliverables (partial completion of the end product or useable intermediate products) on duration boundaries less (1/2 is common on our domains) that match the need for information about physical percent complete

                                On large defense and space programs we work, not work package (a single deliverable) can cross more than accounting period (a month). This means a WP can only be 45 work days long before a complete deliverable to some level of maturity must be produced for a 0%/100% assessment.

                                The hard part is to partition the program into tangible deliverables that represent assessment of progress for the rolling wave. This is the role of Systems Engineering and the Program Planning and Control staff.

                                “What does DONE look like,” must be answered in measures of physical percent complete – this is the basis of ANSI/EIA-748B and a myriad of DoD guidance.

                                This is independent of any method used to produce these artifacts – Scrum, XP, linear development, whatever. Doesn’t matter – but the question of how long is at a maximum 45 working days. This is on programs that last 5 to 7 years.

                                 

                                Glen Alleman

                                 

                                From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Mike Dwyer
                                Sent: Wednesday, March 03, 2010 7:41 PM
                                To: agile-usability@yahoogroups.com
                                Subject: RE: [agile-usability] Death by competitive analysis

                                 





                                William

                                The big false positive in this argument is the continuous deployment.  Remember the annoying browser wars with the unending interruptions to using the web caused by the incessant and annoying updates?  That is one reason, but the best is when your customers call and beg you to stop sending them stuff because they cannot absorb it as quickly as you can deliver it up.  You have to keep in mind that you are part of a supply chain for information use.  What you deliver needs to be integrated into your customer’s environment.  Now this may sound strange but it happens when you start dealing with groups of users.

                                 

                                Mike Dwyer
                                Principal Agile Consultant

                                BigVisible Solutions
                                url:    http://www.bigvisible.com

                                cell:   (978) 376-4422

                                email: mdwyer@...

                                 

                                 

                                 

                                From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of mark schraad
                                Sent: Wednesday, March 03, 2010 9:33 PM
                                To: agile-usability@yahoogroups.com
                                Subject: Re: [agile-usability] Death by competitive analysis

                                 

                                 

                                There truly is not a lot new here. Most of agile is borrowed from design (iterative work, early prototypes, user testing, mini-meetings... et al) and the notion of being in the field with customers... well doh... designers in chicago adopted ethnographic methods back in the early 90's. Competitive analysis is a great tool... but the example shown in the article is pretty lame. There are much better methods and formats. Business and design (and maybe dev folks as well) should be doing their own competitive analysis. The different perspectives all render worthwhile insights.

                                 

                                 

                                 

                                On Wed, Mar 3, 2010 at 8:02 PM, William Pietri <william@...> wrote:

                                 

                                On 03/03/2010 11:54 AM, Glen B. Alleman wrote:

                                Having done 2 startups - one that failed one that went public
                                (www.triconex.com)- I know of no other way to get the first article.
                                Is these really "new" in the sense that it is a new way of doing start ups?
                                  

                                 

                                The Lean Startup stuff? Nothing is truly new under the sun; many claimed there was nothing new about Agile, either. But I think there are several things that distinguish the Lean Startup from both the general-issue Silicon Valley approach and the standard Agile approach:

                                • It's more extreme than XP. For example, instead of just Continuous Integration, the Lean Startup approach recommends Continuous Deployment, where you push to production on every checkin. IMVU, for example, releases  ~50x/day.
                                • There are no requirements; there are only hypotheses in need of testing.
                                • It is focused on users, customers, and markets, rather than grand visions or product plans.
                                • It has a heavy dose of Lean, especially in its approach to cycle time, bug reduction, process refinement, and waste reduction.
                                • Rather than a generic software development process, it is an integrated approach to creating a company, with the focus on inventing/discovering a new product.
                                • It is specifically for creating new products, often ones that disrupt existing markets.
                                • It avoids the "achieving a failure" scenario [1] of big-bang startups.
                                • It splits the process into two different phases: before and after product-market fit is demonstrated.
                                • Average capital requirements are substantially lower.
                                • With its concept of a pivot (radical change in product direction based on feedback), it explicitly encourages a learning-oriented approach to product creation.
                                • Its focus on minimum viable product (MVP) strongly encourages release-early, release-often behavior.


                                For folks interested in the business side of this, and how it fits into the history of Silicon Valley startups, I strongly recommend Steve Blank's blog:

                                http://steveblank.com/

                                For the other side of it, how the Lean Startup works in practice and its relationship to the Agile world, Eric Ries's blog is the source:

                                http://www.startuplessonslearned.com/

                                William




                                [1] http://www.startuplessonslearned.com/2009/01/achieving-failure.html

                                 

                                 





                              Your message has been successfully submitted and would be delivered to recipients shortly.