Provide a clear and intuitive presentation of bundle products in the cart drawer by:Grouping bundled items under a unified visual label or container.Displaying each individual item included in the bundle with clear naming.Ensuring that users can distinguish between standalone products and those that are part of a bundle.

Why another database schema migration tool? Dbmate was inspired by many other tools, primarily Active Record Migrations, with the goals of being trivial to configure, and language & framework independent. Here is a comparison between dbmate and other popular migration tools.

AboutEditCompany

Despite the value of release branches, most of the best teams don't use this pattern for single-production products, because they don't need to. If the mainline is kept sufficiently healthy, then any commit to mainline can be released directly. In that case releases should be tagged with a publicly visible version and build number.

We believe the bill unduly dictates one particular technical approach, and does so without considering the privacy, security, and equity risks it poses.

You must ensure a clear set of information to be added in the design, consistency is the prime requirement for the branding.

:

Such gems like Memoist override methods. So, if you want to memoize a method in a child class with the same named memoized method in a parent class — you have to use something like awkward identifier: argument. This gem allows you to just memoize methods when you want to.

prepared a menu of services

This is the smallest possible actual product that meets the needs ofa specific market of customers.

This certainly includes the functionality—the features.But it also includes the technology that enables this functionality.It also includes the user experience design that presents thisfunctionality.And it includes how we monetize this functionality.It includes how we attract and acquire users and customers.And it can also include offline experiences as well that are essentialto delivering the product’s value.

You can order Correct’s indexcard, dock, and Kokuyo’s fieldnote via the Service page.

There’s not much of a market for what I’m describing.

but from previous experiences like this, the feature set has to be robust at the start or I think adoption will suffer.

macOS should automatically downscale content of documents that are having a single paragraph on the last page.

While helpful at times, these distinctions fail to acknowledge that the quality of the internal tooling and even the technical infrastructure can profoundly impact your customers. The tools you build for your colleagues affect the customer experience and their relationship with your company and its products.

In this paper, we reconsider the major events in the history of life on Earth, from the first cells to the recent technological developments of human societies. We focus primarily on which METs identified by Maynard Smith and Szathmáry (1995) have produced MSTs, either directly or in combination with MCTs and catalysts. In reexamining these major transitions, we also highlight the importance of information for both the METs and the resulting MSTs, and speculate upon the role that Level V dark information may play in a future major transition.

Most typed functional programming languages implement tuples directly as product types

In type theory, product types (with no field names) are generally preferred due to their simplicity

Recent work has revealed several new and significant aspects of the dynamics of theory change. First, statistical information, information about the probabilistic contingencies between events, plays a particularly important role in theory-formation both in science and in childhood. In the last fifteen years we’ve discovered the power of early statistical learning.

Global Engineering

If we hand most, if not all responsibility for that exploration to the relatively small number of people who talk at conferences, or have popular blogs, or who tweet a lot, or who maintain these very popular projects and frameworks, then that’s only a very limited perspective compared to the enormous size of the Ruby community.

ensuring salespeople and customers understand it.

You see — if software is to have soul, it must feel more like the world around it. Which is the biggest clue of all that feeling is what’s missing from today’s software. Because the value of the tools, objects, and artworks that we as humans have surrounded ourselves with for thousands of years goes so far beyond their functionality. In many ways, their primary value might often come from how they make us feel by triggering a memory, helping us carry on a tradition, stimulating our senses, or just creating a moment of peace.

Fluxus was an international, interdisciplinary community of artists, composers, designers and poets during the 1960s and 1970s who engaged in experimental art performances which emphasized the artistic process over the finished product.[1][2] Fluxus is known for experimental contributions to different artistic media and disciplines and for generating new art forms.

At Ipswich, he studied under the unorthodox artist and theorist Roy Ascott, who taught him the power of what Ascott called “process not product.”

Airbnb: This HXC is invested in being a good global citizen, and doesn’t want to simply visit new places but to belong. “It’s the guest who wants to ‘live like a local’ and experience Paris as if they are living there,” says Supan. “They’re energized by the idea of staying in unique spaces and feeling welcomed, but are cost-conscious, too.”Startups like Airbnb that build a two-sided marketplace—guests and hosts, riders and drivers, buyers and sellers, etc.—may be wrangling twice the people, but their process for identifying the HXC doesn’t actually look that different. “The company does have to take a position. While Airbnb will say consistently that the hosts are their business—and that is true—the position of the company is toward the guest. It's about belonging,” says Supan.But there’s no rivalry there; hosts relate to that position. “They, too, want to open their homes to learn about different cultures, and increase their income to be more self-reliant. They understand who Airbnb’s guest is and want to welcome them,” says Supan. “And, many hosts are also Airbnb guests, which is typical of marketplaces where the top sellers can also be the top buyers. Messaging, in these cases, may change depending on which side of the marketplace you’re talking to, but your positioning should not.”

Second, the range of the function must be efficiently computable, and it must be efficiently computable by you.

And in business novices make a product nobody wants.

As simple as Puppeteer, though even simpler.

- Outputs are the things you build. - Outcome is what’s changed for customers, have they become more successful. - Impact is the effect outcomes has on the business like decrease in support costs, increase in conversions etc.

Outcome-focus 就是指公司在乎「成果」大於「成品」的文化，比起做了什麼功能、賺了多少錢，更關注產品改動如何影響終端用戶的行為（User outcome）。

Software Product Engineering and SaaS solutions

Tini differentiates with:

Finally, do note that there are alternatives to Tini (like Phusion's base image).

More importantly, what I like about the simple model is that it is process agnostic.  There are many different discovery processes and techniques, just as there are many different delivery processes and techniques. The higher order points to me are: the activities of discovery and delivery are happening in parallel, ongoing  – they are not “phases” in discovery the team is tackling head-on the big risks – value, usability, feasibility and viability in discovery the product team is working collaboratively to solve problems – product management, product design and engineering the product team measures itself against business results and not just shipping features it is one product team responsible for both discovery and delivery (obviously product managers and designers spend most of their time on discovery activities while engineers spend most of their time on delivery activities).

So when should you use rbspy, and when should you use stackprof? The two tools are actually used in pretty different ways! rbspy is a command line tool (rbspy record --pid YOUR_PID), and StackProf is a library that you can include in your Ruby program and use to profile a given section of code.

By dropping or reducing or postponing the least importantparts, we can unblock ourselves and move forward even when timeis scarce.

Hire our Engineers to solve your complex hardware engineering problems.

This blog is your guide to learn everything about the popular battle; industry design Vs product design Vs UX design.

نرم‌افزارهای نقشه‌ی راه مانند Aha! ،ProductPlan  و Roadmunk  ابزارهای بسیار حرفه‌ای در این زمینه هستند که امکان ساخت نقشه‌های محصول جذاب برای تیم‌های مختلف را فراهم می‌کنند. همچنین با استفاده از این ابزارها و نرم افزار ها می‌توان نقشه‌ی مسیر انفرادی برای هر یک از اعضای گروه تولید درست کرد و سپس برای رسیدن به یک چشم‌انداز و هدف کامل همه‌ی آن‌ها را با یکدیگر همسان سازی کرد. در آخر بعد از انتخاب بهترین ابزار می‌توان ساخت نقشه‌ی راه را آغاز کرد.

Put more simply, the product is dirt — four-and-a-half ounces of it, sealed in a sleek black plastic baggie and sold for $110 plus shipping.

Companies should not assume they can release a product without thinking about its unintended uses and then undo the harm that results. This often doesn’t work.Some technology

இதற்கு அப்பால் மிகச்சிலர் என்னுடைய கருத்துக்களுடன் முரண்பட்டு என் படைப்புக்களில் ஈடுபாடு கொண்டு வாசிப்பவர்களாக இருக்கிறார்கள். எவ்வாறு என இலக்கியம் எப்படி எழுதப்படுகிறதென தெரிந்துகொண்டால் அது உங்களுக்குப் புரியும். இலக்கியப் படைப்பில் ஒரு படைப்பாளி முன்வைப்பது அவன் கற்று, தெளிந்து ஏற்றுக்கொண்டவற்றை அல்ல. அவனுடைய திட்டவட்டமான நிலைபாட்டை அல்ல. இலக்கியப்படைப்பு என்பது ஒருவகை கனவு என எடுத்துக்கொள்ளுங்கள். மொழியில் நிகழும் ஒரு கனவு. ஒரு படைப்பு என்பது அந்த எழுத்தாளன் மொழிவழியாக கண்ட ஒரு கனவு. நம் கனவு நம் கட்டுப்பாட்டில் இல்லை அல்லவா? நாம் நினைப்பதே நம் கனவில் இருக்கவேண்டும் என்பதில்லை அல்லவா? எழுத்தாளன் எல்லாரையும்போல ஒரு அன்றாட உள்ளம் கொண்டவன். அவனுக்கு பல கருத்துக்கள் இருக்கும். அவை அவன் தன் வாழ்க்கையிலிருந்து பெற்றுக்கொண்டவையாக இருக்கும். அவனுக்கான ஓர் அரசியலும் இருக்கலாம். ஆனால் அவன் எழுதுபவை அப்படியே அந்த கருத்துக்களை வெளிப்படுத்துபவை அல்ல. சிலசமயம் நேர்மாறாகவும் இருக்கலாம். அவனே அறியாத நுட்பங்கள் அதில் வெளிப்படலாம். ஆகவே எழுத்தை எழுத்தாளனிடமிருந்து பிரித்தே பார்க்கவேண்டும். எழுத்து தன்னளவில் முழுமையான ஒன்று.

Skills: Imagination Logic Common sense Pattern recognition Basic probability & statistics knowledge

Attitude: Strategic pessimism Non-attachment to one's ideas Confidence in one's ability to influence others

In a world where labs become sustainable by spinning out products, researchers need some way to de-risk their initial work, when they won’t have any new products or technologies to sell. I think this is an effective place for open-ended research grant programs.

How to Create a Minimum Viable Product (MVP): Best Examples and Key BenefitsDmitryCEOMVPProduct GuideHomeBlogEntrepreneurshipHow to Create a Minimum Viable Product (MVP): Best Examples and Key BenefitsPublishedFeb 14, 2019UpdatedNov 26, 202139 min readAs an entrepreneur, you may eventually come to the point of planning a startup and launching your software product. Initially, you only have the idea of the project. What’s next? MVP development for startups is something that will help you at the beginning. You will learn what it is from this article. But first, some statistics. In 2020 the failure rate of startups exceeded 90%. And Euler Hermes’ latest research is even more disappointing. It shows that the number of global business bankruptcies will have increased by 15% by 2022. Can you guess what the reason is? It is a lack of demand among the users in the market. That’s why when you have a brilliant idea, do not rush building a fully-featured product and spending months on hard work. There’s a more efficient way to initially understand whether your idea will be required in the market. And this implies developing a minimum viable product (MVP). This popular approach in startup product development will help you test your business idea and save both time and resources. This way, you understand what users need and can create an offering that they are ready to pay for. Thanks to this article, you will know how to define a minimum viable product. You will also learn all about the MVP approach. We will start with the definition of this term and take a look at the best minimum viable products built by famous companies. Finally, we will provide you with a step-by-step guide on how to create a minimum viable product.

Avoid These Costly Mistakes During Web Application DevelopmentDmitryCEOCustom SoftwareHomeBlogTechnologyAvoid These Costly Mistakes During Web Application DevelopmentPublishedJan 16, 2020UpdatedJan 16, 202015 min readAccording to the Startup Genome Report, over 90% of startups fail after launch. There can be different reasons like skipping the market research, hiring wrong specialists, too early scaling, and so on. However, one of the most important elements of startup success is the product you provide. Neglecting estimates, avoiding the MVP stage, designing unnecessary functionality, and saving time on testing may become fatal errors that can result in a complete failure. In this article, we will tell you about the most costly mistakes you should avoid during web app development to succeed after product launch.

How to Conduct Agile Market Research for Your Digital Product

Spree Commerce: How to Quickly Build an Ecommerce WebsiteAlinaE-Commerce & SaaS StrategistMarketplaceProduct GuideHomeBlogEntrepreneurshipSpree Commerce: How to Quickly Build an Ecommerce WebsitePublishedAug 31, 2020UpdatedAug 31, 202011 min readThe hype around Amazon and eBay has driven up the demand for marketplace development services. Business owners turn to software consultancies to launch a thriving e-commerce website. Here comes a question: what do they need to get the most successful online marketplace website? We believe that a profitable e-commerce project starts with the right tech stack. The main qualities that a modern marketplace should possess are scalability, easy customizations, and flexibility. Therefore, it’s important to choose the technologies that will help these qualities.

POC vs MVP: What to Choose to Build a Great ProductDmitryCEOMVPHomeBlogEntrepreneurshipPOC vs MVP: What to Choose to Build a Great ProductPublishedNov 10, 2021UpdatedNov 11, 202115 min readWhen it comes to creating a new product or implementing a new feature, you need to test it first. The best way to do so is to check your idea with the appropriate steps. There are several software product stages: PoC, prototype, MVP, etc. What is the difference between proof of concept vs. MVP? Why are these stages essential? When should you build a Minimum Viable Product? This article focuses on two fundamental approaches that help test your idea quickly and create a successful solution.

Avere un limite su ogni colonna ti assicura che gli Item si spostino velocemente da una colonna all’altra, visto che questo è l’unico modo per inserire nuovi Item.

Il Pull system funziona in modo diverso, ovvero con un limite sul numero di elementi inseribili in ogni singola colonna della board, questo limite viene chiamato WIP Limit, ovvero Work in Progress Limit.

La principale differenza è che nel Kanban non esistono le sprint. Il processo di sviluppo è continuo.

Per tracciare i progressi si usa una board chiamata Scrum Board, Agile Board o per fare un po’ di casino Kanban Board.Di solito ci sono 4 colonne: To Do, Doing o Progress, Test o QA, Done. La premessa di tutto è che queste due metodologie non sono prescrittive per cui ogni team poi può decidere di aggiungere o rimuovere colonne in base alle proprie esigenze.Il Movimento ideale degli Item sulla scrumboard è da sinistra verso destra, se il movimento è al contrario c’è qualcosa che non va.

Questa parte è il Pull di cui stavamo parlando prima, ovvero gli item vengono “tirati” dal backlog e non “pushati” da qualcun altro.

Quello che accade tra il product backlog, ovvero la mega-lista di cose da fare, e il customer, ovvero l’utente che userà il tuo prodotto, è quello che distingue Scrum da Kanban.

Alcune caratteristiche del Product Backlog:Ogni Item in Backlog deve aggiungere valore all’utente finaleIl Backlog deve essere ordinato e prioritizzatoIl Backlog è un documento vivente. Il processo di revisione e modifica giornaliera del Backlog da parte del Product Owner si chiama Backlog GroomingI dettagli di ogni Item dipendono tipicamente dalla loro posizione sul Backlog: in alto tanti dettagli, in basso pochi dettagli.

Il Product Backlog è  la lista prioritizzata di tutto ciò che si vorrebbe fare (occhio a queste due parole!) all’interno del progetto. Qui sta una delle prime intuizioni semplicissime, ma geniali, dei due metodi.Il fatto che un Item sia in backlog non vuol dire che verrà sicuramente affrontato, sviluppato e rilasciato.

Secondo i principi dell’Agile, come abbiamo visto nel post precedente, il software viene consegnato al customer in piccoli pezzi che incrementano il valore del software progressivamente, inoltre il feedback dal customer viene preso costantemente in considerazione e diventa parte essenziale del ciclo di sviluppo.

n una cascata (waterfall), infatti, l’acqua cade sempre dall’alto verso il basso e così funziona nello sviluppo software Waterfall:Il responsabile di prodotto definisce i requisiti di tutto il progettoIl team di sviluppo realizza il progetto per interoIl progetto viene consegnato al customer tutto in una voltaTutto va nella stessa direzione. Dall’alto verso il basso. Sempre

Nell’esempio di Giuseppe potremmo chiamare la nostra Epic “Funzionalità di login”. All’interno di quest’ultima andremo poi a inserire le varie User Stories come “Frontend – processo login”, “Backend- processo login”, “Processo di recupero password” e così via fino ad aver completato la nostra funzionalità di login.Per non perdere di vista le varie Epic, andiamo a nostra volta a raggrupparle all’interno di “iniziative”. Tornando al nostro esempio possiamo chiamare la nostra iniziativa “Sito e-commerce – primo rilascio”. All suo interno inseriremo tutte le Epic che riteniamo indispensabili per il rilascio del nostro sito.”

Uno dei problemi nell’uso delle User Story è la mancanza di contesto attorno alla storia. Esistono diversi stratagemmi per risolvere.

Questi sono dettagli che vanno aggiunti all’interno della User Story, solitamente si definiscono Criteri di Accettazione. I Criteri di Accettazione sono fondamentali anche per poter verificare se la funzionalità sviluppata rispecchia ciò che era stato deciso. Vi accorgerete che il 90% delle volte ciò che viene implementato non rispecchia quanto era previsto!

Il formato tipico delle User Story ci impone di fare una scelta e decidere le priorità. Quando scrivete una User Story focalizzatevi sempre sulla funzione più importante. Scrivete User Story separate per dettagliare i bisogni differenti. Può creare ridondanza ma vi permetterà di condividere con chiarezza quali sono le priorità.

Come prima cosa descriviamo quale utente stiamo servendo. A prima vista si potrebbe pensare che l’utente è unico per un prodotto. In realtà ogni prodotto ha una varietà di utenti con diversi intenti.In un e-commerce possiamo sicuramente distinguere tra utenti alla prima visita, utenti registrati, utenti che hanno fatto 1 o più acquisti, e così via. Inoltre molti prodotti hanno alle spalle un servizio e spesso una parte dello sviluppo è dedicata ad utenti interni come per esempio il servizio clienti.

Le User Story hanno solitamente il seguente formato:Come [descrizione dell’utente], voglio [funzionalità o azione] in modo che [obiettivo o valore per l'utente].

L’utente a cui ci stiamo rivolgendoil bisogno che vogliamo soddisfareil motivo per cui dobbiamo soddisfarlo. Un po’ di esempi pratici renderanno tutto molto più chiaro!Ma, prima di partire con gli esempi, voglio dirvi quali sono per me le 2 caratteristiche essenziali delle User Story: chiarezza e confronto.

Il concetto più interessante che introducono le User Story è quello di mettere l’utilizzatore del nostro prodotto (lo User) al centro dell’attenzione durante il processo di sviluppo. Pari importanza è data anche all’identificazione del bisogno che ogni funzionalità promette di soddisfare (la storia).

Mi piace molto la definizione di User Story di Mike Cohn: ogni User Story è la promessa di una conversazione. Per Mike quello che c’è scritto nella User Story non è molto importante, è solo un promemoria per innescare una discussione con tutto il team.

Lo Sprint inizia con lo Sprint Planning dove il Product Owner prioritizza il Product Backlog ed insieme al team crea lo Sprint Goal, ovvero l’obiettivo da raggiungere per la Sprint in partenza.

In alcuni casi viene anche chiamato Agile Coach. Lo Scrum Master è colui/colei che si adopera per far si che il team raggiunga la massima produttività ed efficienza. È il facilitatore di tutte le cerimonie Agile tramite tecniche di negoziazione e mediazione.È anche la voce del team di sviluppo. Chi promuove la metodologia Scrum e fa sì che i suoi principi/valori vengano applicati in maniera corretta tramite un durissimo lavoro di coaching e mentoring. Lo scrum master si occupa anche delle metriche di avanzamento per fare venire a galla i problemi, ma anche i successi del team. 

È colui/colei che guida il team nella giusta direzione, che prioritizza le user storiy e come un direttore d’orchestra si interfaccia con gli stakeholders e col team per far in modo che tutto funzioni alla perfezione. 

Le skills/conoscenze individuali devono essere trasferite al team tramite peer programming (sviluppo di una funzionalità a due mani) o mob programming (sviluppo a più mani). Questo porterà il team nel lungo periodo ad essere molto più efficiente, dato che ogni membro del team avrà come bagaglio la conoscenza del prodotto e del software utilizzato e potrà essere intercambiabile.Tipicamente un team cross funzionale è composto da Product Manager, Design, Sviluppo, Data Analysis.

È un momento di ispezione per tutti, per i processi, per le persone e per il modo in cui si lavora. Qui si ispeziona quel che è stato fatto chiedendosi:Cosa è andato bene?Cosa potrebbe andare meglio?Quali sono gli improvement / miglioramenti che si possono implementare nel prossimo Sprint?

L’incremento, ovvero la somma delle funzionalità che si sono sviluppate durante lo sprint vengono finalmente mostrate al cliente e ai più importanti stakeholders del progetto. Qui si riceve il feedback che porterà a decidere quale corso il prodotto deve prendere e quali user story saranno prioritizzate nel prossimo sprint.La Sprint Review non è solo una Demo, ma è l’elemento di raccordo con la Sprint precedente: un incontro fondamentale su cui costruire la cultura, creare prodotti migliori e rinforzare la fiducia del team.Queste sono alcune delle attività:Definire cosa è stato completato e cosa no, commentando il lavoro.Demo individuali Rivedere impatto delle feature su Metriche ChiaveVerifica User Story e aggiunta nuove per completareBacklog Grooming

La cosiddetta stima dell’effort è un concetto fondamentale, specie nel Backlog Refinement e in Sprint Planning dove il team di sviluppo si riunisce per dare un valore numerico alle user stories. Questo aspetto non è assolutamente da sottovalutare, perché dalla stima delle user story possono scaturire tantissime discussioni interessanti per capire effettivamente il grado di rischio, complessità, fattibilità di ciascun task.L’estimation a differenza degli altri rituali non ha una sua precisa collocazione, può essere fatto in qualsiasi momento, ma considera che il Team dovrebbe dedicare al meno il 10% del suo tempo alla stima del lavoro necessario per sviluppare una User Story.

Lo Sprint Planning è forse uno dei meeting più importanti nelle cerimonie Agile ed è il momento in cui business (product owner) e technical team si riuniscono per decidere cosa faranno nella prossima iterazione/sprint. Di solito dura circa 4 ore ed avviene il giorno prima dell’avvio della sprint.L’obiettivo dello Sprint Planning è proprio quello di pianificare la Sprint definendo l’Outcome (L’obiettivo di sprint) e passando dalle user story alle singole task per ciascun componente del team.

il daily scrum è un meeting giornaliero dove il team si riunisce e raccoglie le proprie impressioni su come sta andando lo Sprint e quanto ci si sta avvicinando o allontanando dallo Sprint goal. Ogni membro deve rispondere a tre domande ben precise:Cosa ho fatto ieri?Cosa ho fatto oggi?Ci sono impedimenti che stanno bloccando il mio percorso nel raggiungere lo Sprint Goal?

Daily Scrum: allineamento giornaliero Sprint Planning: preparazione della SprintEstimation: stimare il peso di ogni user storySprint Review: demo e review del lavoro svoltoSprint Retrospective: migliorare il modo in cui si lavora insieme.

Man mano che passano le sprint il team di lavoro acquisirà il proprio ritmo, “heartbit” o velocità.La Velocity è la somma degli story point completati a fine sprint. Questa servirà da metro di paragone per pianificare gli Sprint successivi.Facendo un passo indietro infatti ogni User Story prima di essere portata in sviluppo deve essere analizzata e ne deve essere valutato il peso in termini di impegno del team.Es: una User Story che pesa poco impegna solo alcuni membri del team (anche uno solo) per poco tempo, una Storia che pesa molto impegna tanti membri del team per tanto tempo.Solo dopo aver dato un valore ad una User Story usando appunto gli Story Points, questa può essere aggiunta allo Sprint Backlog.

La User Story è la funzionalità o l’incremento di prodotto che si vuole portare in sviluppo scritta dal punto di vista dell’utente. Ogni User Story incorpora al suo interno CHI beneficerà di quella funzionalità, COSA si richiede e PERCHÈ è importante per l’utente

Il backlog è la lista di user stories o task che non è ancora stata introdotta nello Sprint e risiede in uno spazio apposito. Considerala come una wishlist di funzionalità che potrebbero essere implementate e che saranno prioritizzate dal product owner durante lo Sprint Planning.

Anche chiamato “iterazione” è un lasso di tempo che può variare da uno a quattro settimane dove il team si adopera per creare un “incremento”, un prodotto/funzionalità, anche non finito, che crea valore e che può essere ispezionato alla fine, ricevendo feedback positivi/negativi dagli stakeholders interessati.Nello Sprint si usa il concetto di time-box, dove all’inizio del progetto si decide quanto l’iterazione debba essere lunga (da una a quattro settimane, non di più)

Agile Scrum è a tutti gli effetti un sistema di regole, procedure e rituali ben definiti su come applicare la metodologia Agile, dove, come ho detto qualche riga prima, il tempo è l’elemento più importante.A scandire il tempo in Agile Scrum ci pensano gli Sprint, dei piccoli time-frame in cui il team di sviluppo lavora per il rilascio di una o più funzionalità.

Nel rugby, la parola “Scrum“ è un termine usato per spiegare il goal del team di ottenere il possesso della palla in quanto unità molto coesa. In maniera simile, in Agile Scrum, il team di sviluppo lavora insieme per raggiungere uno o più obiettivi alla fine dello Sprint/iterazione. 

Qui di seguito ti riassumo quali sono i punti chiave:Accettare l’incertezza e tutto ciò che ne derivaIl fallimento è la via più sicura per imparareSe non lo misuri non lo saiFiducia nelle persone e nella loro capacità di avere impattoOwn your Outcome: assumersi la responsabilità a tutti i livelli

fino a quel momento tutta l’attenzione nel processo tradizionale di sviluppo software, chiamato Waterfall, era stata posta su documentazione, processi e specifiche tecniche, adesso la lente si spostava sulle persone e sulle interazione tra di esse, sui team e sul loro spirito di adattamento e risposta al cambiamento.

Come si sarà intuito, non c’è PMM senza PM. La relazione tra i due ruoli è strettissima: alcuni dicono che al PM spetta mettere il prodotto “on the shelf”, e che il PMM deve invece assicurarsi che venga comprato, e quindi preso “off the shelf”. Il PM è quello che inquadra il problema e definisce la soluzione; il PMM in questa fase fornisce al PM input come le tendenze di mercato e concorrenziali; il PM orchestra il lavoro degli sviluppatori per creare il prodotto; nel frattempo il PMM inquadra il posizionamento e crea il messaging; il PM definisce la strategia di lancio; il PMM crea e orchestra l’esecuzione del go to market plan. 

Essenzialmente il Product Marketing è il processo che punta a mettere un prodotto sul mercato. Questo significa definire il posizionamento strategico del prodotto, il messaging, e anche assicurare che i team di Vendite siano in grado di venderlo (se si è del comparto B2B). In altre parole, il Product Marketing crea e stimola la domanda per il prodotto di cui si occupa. In molti la considerano una funzione ‘fondante’ del marketing.

quattro pillar fondamentali del Product Marketing, ovvero Intelligence, Positioning, Launch, Enablement

First, set clear goals and prioritize among conflicting goals (for instance, price to maximize revenue but ensure a 10 percent profit increase).Second, pick one of the three types of pricing strategies: maximization, skimming, or penetration.Third, set price-setting principles that define the rules of your monetization models, price differentiation, price endings, price floors, and price increases.Finally, define your promotional and competitive reaction principles to avoid knee-jerk price reactions.

A pricing strategy is your short- and long-term monetization plan. The best companies document their pricing strategies and make it a living and breathing document.

What monetization model do we envision for our new product? Why is it the right one, and how did we choose it?Which models did we not pick, and why?What are the most important trends in our industry? How do they affect our choice of a monetization model? How do we plan to monetize our product if customer usage varies significantly? Which price structures have we considered and why?Do we have the right capabilities and infrastructure to execute the chosen monetization model and price structure?

To have a chance at converting free customers to paid customers, you need to test what benefits they will pay for and ensure a functional free experience. You also need to know exactly how many customers will actually be willing to pay. What’s more, you must avoid giving the farm away for free because it will leave your premium offering with very little value.

Customers pay when they use or benefit from the product. This can be exceptionally successful if you can align the metric directly to how customers perceive value. This can be effective if you are adept at predicting future trends. The alternative pricing model makes sense when your innovation creates significant value to end customers but you cannot capture a fair share of that value using traditional monetization models.

Auctions — competition based pricing for goods and services. Google AdWords, eBay, and other two-sided marketplaces use auctions. Market determines price. If you can control inventory for an in demand product, you should consider this model.

Dynamic pricing — airline industries, Uber offer dynamic pricing for peak demand times. Dynamic pricing boosts the monetization of fixed and constrained capacity. Complex model requiring extensive data analytics.

Subscription —recurring revenue increases customer lifetime revenue, revenue predictability, cross-sell and upselling opportunities. Works well in online and offline services where the product is used continually, in competitive industries, and where it can reduce barriers to entry through large upfront payments.

What are the product configuration/bundles we plan to offer? Why did we pick these offers? Do they align with our key segments? If not, why not?What are the leader, filler, and killer features for the new product or service our company is developing? How did we find out?Have we explored a good/better/best approach to product configuration and bundling? What do we expect sales to be for each product configuration? Is the share of the basic product configuration lower than 50 percent? If not, why not?Have we explored bundling our new product with existing products? What would be the benefits for us and the customers?Have we considered unbundling as an opportunity? What would be the benefits to customers and our business (if any)?

Align offers with segmentsDon’t go beyond nine benefits or four productsCreate win-win bundles for you and the customerDon’t give away too much in the entry-level product. Look at customer distribution by product and upsell percentage to qualify a problemHard bundles might not work and an a la carte bundle may be betterPer product pricing needs to be higher than bundled pricingMessaging and communicating the value of the bundle is a sales opportunity depending on what product or feature they are afterBundle an integrated experience and charge a premium instead of a discountDon’t bundle for the sake of bundlingLook for inverse correlations and exploit both by including the nice to have inverse.

Establishing which features are leaders (must-haves), fillers (nice-to-haves), and killers (features that are deal killers), andCreating good/better/best options.

Product configuration and bundling are your key building blocks for designing the right products for the right segments at the right price points. Product configuration is about putting the appropriate features and functionality — those customers need, value, and are willing to pay for — into the product; this process has to be done for each identified segment. Systematic product configuration prevents you from loading too many features into a product and producing a feature shock.

Does our product development team have serious pricing discussions with customers in the early stages of the new product’s development process? If not, why not?What data do we have to show there’s a viable market that can and will pay for our new product?Do we know our market’s WTP range for our product concept? Do we know what price range the market considers acceptable? What’s considered expensive? How did we find out?Do we know what features customers truly value and are willing to pay for, and which ones they don’t and won’t? And have we killed or added to the features as a consequence of this data? If not, why not?What are our product’s differentiating features versus competitors’ features? How much do customers value our features over the competition’s features?

Did we segment before we designed the product? If not, why not?What were the segments? How did we get to these? Which ones would we serve initially? Do they represent a sizable market?What criteria were they based on? How different are these segments in their WTP? Can we respond differently to each segment? If so, how?How did we describe the segments? What observable criteria do we have in these descriptions? Do our descriptions and observable criteria on each segment pass our sales team’s sniff test?How many segmentation schemes do we have in our company? Can we consolidate to one segmentation across product, marketing, and sales?Who in our company is responsible for segmentation? At what point in the innovation cycle does this person (or people) get involved?

Do Segmentation Right:Begin with WTP data — By clustering individuals according to their WTP, value, and needs data, you will discover your segments — groups of people whose needs, value, and willingness to pay differ.Use common sense — Practicality and common sense are as important as statistical indicators.Create fewer segments, not more — Serving each new segment adds significant complexity for sales, marketing, product and service development, and other functions. Smart companies start with a few segments — three to four — and then expand gradually until they reach the optimal number.Don’t try to serve every segment — The products and services you develop should match your company’s overall financial and commercial goals. A segment must deliver enough customers — and enough money — to make the investment worthwhile.Describe segments in detail in order to address them — Investigate whether each segment has observable criteria for customizing your sales and marketing messages to them.

The message here is clear: You need to create segments in order to design highly attractive products for each segment. And you must base your segmentation on customers’ needs, value, and WTP. This way, segmentation becomes a driver of product design and development, not an afterthought.

Everything a Product Owner Needs to Know Before Starting a Software Development Project

Do not use articles in front of product names. For example, do not write "the JBoss Enterprise Application Platform was..."

Using "the" with product names

How Much Does it Cost to Build a Website Like IndeedDmitry ChekalinChief Executive OfficerProduct GuideHomeBlogEntrepreneurshipHow Much Does it Cost to Build a Website Like IndeedJan 23, 202021 min readJob search websites have revolutionized the employer-employee relationships. No printed classifieds on the walls and no extra movements. Everything you need to do is to visit such a platform, enter the position details and choose the most relevant option to hire or apply for. Indeed is the most visited platform among other job-related online marketplaces. In this article, you will find out what makes Indeed so famous and special. Besides, we will discuss the challenges you may face before and during the development process, the things to consider before starting, and the functionality your platform should have. On the whole, you will know how to create a job search website like Indeed using 3 effective solutions.

Looking deeper, you can see a large amount of issues open, bugs taking months to fix, and pull requests never seem to be merged from outside contributors. Apollo seems unfocused on building the great client package the community wants.

This sort of behaviour indicates to me that Apollo is using open-source merely for marketing and not to make their product better. The company wants you to get familiar with Apollo Client and then buy into their products, not truly open-source software in my opinion. This is one of the negatives of the open-core business model.

“minimum viable paper” (MVP) – similar to the corporate world’s minimum viable product

Product Goals with quarterly business reviews

Introduction of Product Goal


A generic trademark, also known as a genericized trademark or proprietary eponym, is a trademark or brand name that, because of its popularity or significance, has become the generic term for, or synonymous with, a general class of products or services, usually against the intentions of the trademark's owner.

The privacy policy — unlocking the door to your profile information, geodata, camera, and in some cases emails — is so disturbing that it has set off alarms even in the tech world.